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/
Related
We currently use Traefik IPWhiteList middleware to restrict the access to our application. If the Ip address is not on the whitelist, Traefik sends back a 403 forbidden. The user should now be redirected to another page. unfortunately I can't find a way to set this up. is there a possibility that I have missed or is this really not possible with Traefik?
First you have to create both Middlewares errors and ipwhitelist, as you can see in the image down below from line 62:
After, you have to link the Middlewares to your service, as you can see on line 108:
You must link the error Middlewares first
Then, create the endpoint which will return the response, for instance:
And you will receive the following response
I need to download a file from an http location to my local system using apache camel. When I gave the below code
from("http://url/filename.xml")
.to("file://C:location")
it has worked for ftp but not working when the url is "http". That is, it is not downloading the file from the http location to the local address provided in the "to()".
This should work.
from("direct:abc")
.setHeader("Accept", simple("application/xml"))//Change it according to the file content
.setHeader(Exchange.HTTP_METHOD, constant("GET"))
.to("http://url/filename.xml")
.to("file:///tmp/?fileName=yourFileName.xml");
You cannot use from("Some url"). Above route is triggered whenever there is a message on direct:abc endpoint. You can change the yourFileName.xml to whatever filename you want it to be stored as.
Instead of a trigger from route, you can as well use a timer or any other means of self triggering.
The reason you cannot consume from a rest enpoint like this
from("http://url/filename.xml")
is you cannot consume from http endpoint. So there needs to be a trigger. Infact the exception message is pretty clear when you do like this. It says
org.apache.camel.spring.boot.CamelSpringBootInitializationException: org.apache.camel.FailedToCreateRouteException: Failed to create route route1: Route(route1)[[From[http://url/filename.xml]] -> [To[... because of Cannot consume from http endpoint
the http component cannot be used as a consumer ie. you cannot have a route as from("http://...")
you need to use a consumer component that will start the route.
You could try something like this
from("timer:foo?fixedRate=true&period=5000")
.to("http://url/filename.xml")
.to("file://C:location")
I have an api gateway endpoint and I want to be able to access it from my webpage; the api gateway will response with a string.
I would like to make an ajax request to the endpoint then use the response of that to do my work on the ui.
So in my proxy.conf file, I added:
ProxyPass /proxyme https://API_ENDPOINT
ProxyPassReverse /proxyme https://API_ENDPOINT
When I execute:
$.get("API_ENDPOINT")
I get a 404. Am I missing something to make this proxy work? I'm sure that I restarted my apache when I added the proxy.
Please let me know if additional detail is needed.
Edit:
Does it matter if my site is http and gateway is https?
Edit 2:
My object is to have my frontend js code hit some url:
/proxyme
and it should hit the api endpoint via a proxy:
https://API_ENDPOINT
once the data is received, my js will kick in and do rendering.
HTTP to HTTPS is a big no no and there's no way around it.
I want to use an Apache proxy server (mod_proxy) to intercept all requests and responses to a web server. However I want to change requests and responses before redirecting them. Simply rewriting URLs is easy and documented, but the changes I want to make are more sophisticated, namely they need to inspect the request for user credentials as well as conditionally make redirects.
Is this possible in Apache's mod_rewrite, possibly in combination with other modules?
While the main goal is to implement this in Apache, I would also be happy with an alternative solution which doesn't necessarily use Apache.
Here is a more precise explanation of what I want to achieve, to give a little more context:
Check each incoming request for user credentials. If credentials are present, they are replaced by the user information which the web server can use to identify the user (Ideally in the Authorization header)
For example, let's assume a request contains a cookie which authenticates the request as beeing sent from the user "John", this cookie is removed, and the Authorization header is changed to Authorization Authenticated_by_proxy {"id":12345,"name":"John"}
Check each answer to see if it's an Error 403. If this is the case and the user is not logged in, redirect the user to a login page instead of forwarding the error
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.