0

I'm having an issue with a few server requests that have left me scratching my head. The situation is that some of my forms are POSTing to the server without issue, but then others are being redirected from HTTPS to HTTP, to the same URL but as GET requests, So, when my script gets the request there is no POST data.

I've checked my .htaccess and that looks fine to me, but also, I don't see why that would cause this (admittedly I'm no Apache superstar).

I added a debugger to halt on the first line of code in my app, and the request at that point is already changed, which is what leads me here.

This first image shows a secure POST request being sent from the page POST request

The second image shows the unsecure redirect as a GET request GET request

And my .htaccess looks like this

<IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteBase /

    # Redirect all HTTP requests to HTTPS
    RewriteCond %{HTTPS} off
    RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

    # Ensure the correct handling of index.php, site.php, and cp.php
    RewriteRule ^(index|site|cp)\.php$ - [L]
    RewriteRule ^(css|js|img)/ - [L]
    RewriteRule ^favicon.ico$ - [L]

    # Redirect all other requests to the appropriate PHP file
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule ^(.*)$ /index.php [NC,L,QSA]
</IfModule>

As you can see I have 3 points of ingress into the application index.php for guest requests, site.php for authenticated users, and cp.php for admins (control panel). These help with routing and are very similar (bootstrap the system, authenticate, handle the request).

The form I'm rewriting right now is the 2nd form this is happening to, and other than the action attribute they look the same. I've tried with and without an enctype, I've tried different browsers, and I've rebooted and rebuilt the docker container to find the reason for this issue.

There is no framework other than the one I built, this is vanilla PHP, but as I think we can see this is not a code issue.

7
  • Can be there any redirects or other nontrivial things in the main configuration? (By the way, why using not-recommended .htaccess at all instead of just including its content into appropriate <Directory> block in the main configuration?) Commented Sep 18 at 8:12
  • You post to a URL and immediately get a redirect to the same path on a different scheme. This looks exactly like a broken PRG pattern. You should search your php code for header( calls and instrument them.
    – symcbean
    Commented Sep 18 at 10:51
  • @NikitaKipriyanov You're right, I should. I inherited the project this way so left it in place, plus the fact the 95% of form posts work and then some simply don't, to me sounded like non-simple matter Commented Sep 18 at 18:26
  • @symcbean I stopped execution before any PHP code runs so I don't think this is a code issue at all. The request goes to the server and is redirected to the GET version immediately at the server level. Commented Sep 18 at 18:27
  • Presumably there is another (2nd) redirect back to HTTPS (by the directive in .htaccess)? If not, why not? But if so why is there no redirect loop (or is there)? What are the complete HTTP response headers for the initial 302 redirect? Do you see a Server header? When the "browser" encounters a 302 redirect the "browser" (not server) will convert a POST request to GET and the POST data is naturally lost - this is expected behaviour. The problem is where this 302 is being triggered - there is nothing in what you've posted that helps in this respect. (A Server header might give a clue.)
    – MrWhite
    Commented Sep 20 at 13:10

1 Answer 1

0

Ok, so while doing some unrelated debugging, my IDE put up a dialog because it couldn't find the correct path in my local codebase for the one on the server. I thought that it was very strange because I'd been working in that area all day...well, not quite. I had clicked on a link in a menu for the page I was working on, and the dang link didn't have a request scheme on it, it was just a relative link. So, the server returned the page over HTTP (no S) and that in a nutshell was the problem.

I've always assumed if a relative link is clicked on a page served over HTTPS, that page would be returned over HTTPS...but that's not the case here. As this is something I've always assumed over 20 years, I'd be very shocked if I'm wrong, so there may be a different issue casing this.

At least I know why, in this instance, this is happening.

Thanks for the comments.

1
  • Even with my .htaccess in place! Ok, well time to over that to into the Apache config for the site. Commented Oct 9 at 22:43

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .