Got a really strange problem here. When sending post requests to my PHP script
$_SERVER['REQUEST_METHOD']
returns "GET" instead of "POST".
It works fine for every other REST method
so this is what I get
GET -> GET
POST-> GET
PUT -> PUT
DELETE -> DELETE
It only happens on one of my servers so i'm assuming it's an apache problem and i've managed to figure out that it only happens if I add "www" to my url.
I.e
www.something.com
causes the problem but
something.com
does not
I have tested on different sites on the same server and I get the same thing so I'm assuming it's global config.
Any thoughts
As the HTTP spec says for response codes 301 and 302:
Note: For historic reasons, a user agent MAY change the request method
from POST to GET for the subsequent request. If this behavior is
undesired, the 307 (Temporary Redirect) status code can be used
instead
A third (but unlikely) possibility is you're getting a 303 response to the initial URI. The solution is twofold:
Configure the clients which are under your control to POST to the canonical URI so they are not redirected at all.
Configure your server to redirect using 307 in this case instead of 301/302.
Related
I'm trying to use nginx to serve a custom error page using the Error Page middleware so that 404 requests to a lambda service (which I don't control) can be handled with a custom error page. I want to be able to get the context of this original request on that error page, either in Nginx for further forwarding, or else as a header for further handling e.g. in PHP or whatnot so I can provide contextual links on the 404 page.
However, right now after the redirection to Nginx in Traefik's ErrorPage middleware it seems the request has lost all the headers and data from the original service query.
The relevant part of my dockerfile:
traefik.port=8080
traefik.protocol=http
traefik.docker.network=proxy
traefik.frontend.rule=PathPrefix:/myservice;ReplacePathRegex:^/myservice/(.*) /newprefix/$$1
traefik.frontend.errors.myservice.status=404
traefik.frontend.errors.myservice.service=nginx
traefik.frontend.errors.myservice.query=/myservice-{status}
Nginx receives the forwarded 404 request, but the request URI comes through as nothing more than the path /myservice-404 specified in query (or /, if I omit traefik.frontend.errors.myservice.query). After the ReplacePathRegex I have the path of the original request available in the HTTP_X_REPLACED_PATH header, but any query arguments are no longer accessible in any header, and nginx can't see anything else about the original URI. For example, if I requested mysite.com/myservice/some/subpath?with=parameters, the HTTP_X_REPLACED_PATH header will show /myservice/some/subpath but not include the parameters.
Is it possible in Traefik to pass another service the complete context about the original request?
What I'm really looking for is something like try_files, where I could say "if this traefik request fails, try this other path instead", but I'd settle for being able to access the original, full request arguments within the handling backend server. If there was a way to send Nginx a request with the full path and query received by Traefik, that would be ideal.
tl;dr:
I am routing a request to a specific service in Traefik
If that request 404s, I want to be able to pass that request to Nginx for further processing / a contextual error page
I want Nginx and/or the page which receives the ErrorPage redirect to be able to know about the request that 404'd in the service
Unfortunately this is not possible with Traefik. I tried to achieve something similar but I realized that the only information that we are able to pass to the error page is the HTTP code, that's it.
The only options available are mentioned in their docs: https://doc.traefik.io/traefik/middlewares/errorpages/
I'm having the SSL warning messages all over my website after switching to SSL for several assets:
Mixed Content: The page at 'https://example.com' was loaded over HTTPS,
but requested an insecure script 'http://example.com/script.js'. This
request has been blocked; the content must be served over HTTPS.
I checked the page source, every single script/css is requested over https.
I even checked the dynamically created html by using the code inspector.
I disabled Javascript in case a script was loading these assets dynamically.
None of these things showed a single http:// request. I'm out of ideas to try and find what is causing this. Any ideas or suggestions?
When seeing a mixed-content message about a http://example.com/script.js (non-https) URL that doesn’t actually appear anywhere in your sources, the basic strategy to follow is:
Replace the http in the URL with https and put that into the address bar in your browser: https://example.com/script.js
If your browser redirects from that https://example.com/script.js URL back to (non-https) http://example.com/script.js, then you’ve found the cause: example.com/script.js isn’t actually available from an https URL, and ends up getting served from a http URL even though your source is requesting the https URL.
My 2 cents regarding this issue.
I have a project hosted on one domain that works flawlessly.
I need to make it international so I am cloning the master branch to a new branch, making some necessary text changes and deploying new site (new domain) with code from the new branch.
Everything works fine, except 1 ajax call (api route) that gets blocked due to Mixed content.
First things first, I checked these 3 things:
I check in the Network tab in dev tools and it is actually loaded through https.
I open the file directly in browser and it is https.
I try to open it as http:// and it automatically redirects to https://
This is very strange because the 2 domains are both using Cloudflare and their backend setup is identical, the code is the same (only text changes for the new one) yet for the new setup there is console error for 1 specific api route, an all others (some 20+ ajax requests across the page) work just fine. They are even using the same function to make the Ajax request, so it is definitely not a configuration error.
After doing some investigation I found out the issue:
The call that was 'buggy' was ending in /. For example, all other calls were made to:
https://example.com/api/posts
https://example.com/api/users
And this particular one was making requests to
https://example.com/api/todos/
The slash at the end was making it fail with mixed content issue. I am not sure why this is causing issue and how it isn't an issue on the original site (since there the same ajax call works just fine), but it definitely fixed my issue.
If I figure out what caused the / to fail so miserably, I will post an update.
We attempted a passbook program but it never made it out of beta, but there are a few passes out there that keep phoning home (and throwing errors because the passes are out of sync with existing data). My plan is to 404 any incoming requests, but I'm not sure if that is the best way to handle existing passes. Any other ideas or is 404 the right solution?
There are a few of options:
Return an updated pass without that has a blank web service url
Return an appropriate error
Remove the DNS entry of the subdomain
Update the web service url
Any of the fields in the pass can be updated including the web service url. Removing the url will prevent further requests for updates. This s potentially the most effective, but would require a bit of development to return the updated pass and would need to be maintained until all passes have been "disabled."
Return an appropriate error code
It may be easier to simply return an error code. This could be done through the web server configuration preventing the requests from being processed by your application (and presumably stop the errors in the application). This would allow you to remove the code altogether from your application.
The Passbook Web Service Reference indicates that Passbook will eventually give up when receiving persistent errors.
If a request fails—for example, due to a network connectivity issue—Passbook tries again several times after waiting a period of time. Each time it tries again, it waits longer. If the request continues to fail, it eventually gives up.
The documentation also indicates that standard HTTP status codes should be used in the response from the call to Getting the Latest Version of a Pass (and others).
Response
If request is authorized, return HTTP status 200 with a payload of the pass data.
If the request is not authorized, return HTTP status 401.
Otherwise, return the appropriate standard HTTP status.
Discussion
Support standard HTTP caching on this endpoint: check for the If-Modified-Since header and return HTTP status code 304 if the pass has not changed.
It sounds like the ending of the passbook program is permanent in which case 410 Gone would be an appropriate error code. (From RFC 2616).
410 Gone
The requested resource is no longer available at the server and no forwarding address is known. This condition is expected to be considered permanent. Clients with link editing capabilities SHOULD delete references to the Request-URI after user approval. If the server does not know, or has no facility to determine, whether or not the condition is permanent, the status code 404 (Not Found) SHOULD be used instead. This response is cacheable unless indicated otherwise.
The 410 response is primarily intended to assist the task of web maintenance by notifying the recipient that the resource is intentionally unavailable and that the server owners desire that remote links to that resource be removed. Such an event is common for limited-time, promotional services and for resources belonging to individuals no longer working at the server's site. It is not necessary to mark all permanently unavailable resources as "gone" or to keep the mark for any length of time -- that is left to the discretion of the server owner.
Remove subdomain DNS
If your web service url was set up on a separate subdomain (e.g. passbook.example.com) you can simply remove the DNS entry for the subdomain. The requests will never reach the server and Passbook will eventually give up.
My Question is this
I redirect the form in
Redirect /formviewer/faces/pages/view/viewform.xhtml
///formviewer/faces/pages/view/viewform.xhtml
in Apache Http Server but the form is not redirecting while doing post request from client Side.
So what is it doing?
I rather suspect that its normalising the thing you want to redirect to ///... and considering it the same.
When looking at redirects, there are three things in my list of 'go-to' tools:
curl -I http://..... and look at the response and the Location header. I use this when installing new redirects (it avoids following chained redirects and gives me a better view of what is happening at each step.
Something like Fiddler or a browsers developer tool. Frankly I'd only use this if curl wasn't doing it for me.
Enable the RewriteLog in Apache... I almost never use this, but for your case it may shed some light.
But let's take a step back: why are you wanting to redirect to a path with and extra // prepended (which as I've previously speculated, likely won't work)?
I have implemented SEO URLs using Apache 301 redirects to a 'redirect.cfm' in the root of the website which handles all URL building and content delivering.
Post data is lost during a 301 redirect.
Unable to find a solution so far, have tried excluding post method from rewrites - worst case scenario we could use the old type URLs for post methods.
Is there something that can be done?
Thanks
Using a 307 should be exactly what you want
307 Temporary Redirect (since HTTP/1.1)
In this case, the request should be repeated with another URI; however, future requests
should still use the original URI.[2] In contrast to how 302 was historically implemented,
the request method is not allowed to be changed when reissuing the original request. For
instance, a POST request should be repeated using another POST request
- Wikipedia
Update circa 2021
The original answer here was written before 307 status code redirect worked consistently across browsers. As per Hashbrown's answer below, the 307 status code should be used.
Old Answer
POST data is discarded on redirect as a client will perform a GET request to the URL specified by the 301. Period.
The only option is to convert the POST parameters to GET parameters and tack them onto the end of the URL you're redirecting to. This cannot be done in a .htaccess file rewrite.
One option is to catch POST requests to the url to be redirected and pass it off to a page to handle the redirect. You'd need to do the transposition of the parameters in code then issue the redirect header with the parameter appended new url that way.
Update: As pointed out in the comments to this answer, if you do redirect to another URL specifying POST parameters and that URL is also accessed without paramters (or the params are variable), you should specify a link to the canonical URL for the page.
Say the POST form redirects transposed to the following GET resource:
http://www.example.com/finalpage.php?form_data_1=123&form_data_2=666
You would add this link record to the head section of the page:
<link rel="canonical" href="http://www.example.com/finalpage.php" />
This would ensure all SEO value would be given to http://www.example.com/finalpage.php and avoid possible issues with duplicate content.
Using 301 redirects for general URL rewriting is not the way to go.
This is a performance issue (especially for mobile, but also in general), since it doubles the number of requests for your page.
Think about using a URL rewriting tool like Tuckey's URLrewriteFilter or apache mod_rewrite.
What Ray said is all true, this is just an additional comment on your general approach.