I'm curious how the 305 Use Proxy HTTP Response Header is implemented by the latest web browsers.
What I'm hoping to accomplish is effectively as follows:
Accept a request using Apache
Provide a response to the browser which will indicate it should make
the request again, on another port and/or hostname for the server
Fork and detach the original request
Listen on the port indicated to the browser, and handle the HTTP
request in full by the child process
It would only be effective for my purposes if the browser does not indicate to the user the request is now being server by the child process, for this reason, 301/302 won't be effective.
http://trac.tools.ietf.org/wg/httpbis/trac/ticket/76
Related
Are there any specific spec'd processes that a browser client can use to dynamically encourage a server to push additional requested items into the browser cache using HTTP/2 server push before the client needs to actually use them (not talking about server-side events or WebSockets, here, btw, but rather HTTP/2 server push)?
There is nothing (yet) specified formally for browsers to ask a server to push resources.
A browser could figure out what secondary resources needs to render a primary resource, and may send this information to the server opportunistically on a subsequent request with a HTTP header, but as I said, this is not specified yet.
[Disclaimer, I am the Jetty HTTP/2 maintainer]
Servers, on the other hand, may learn about resources that browsers ask, and may build a cache of correlated resources that they can push to clients.
Jetty provides a configurable PushCacheFilter that implements the strategy above, and implemented a HTTP/2 Push Demo.
The objective of server push is that the server send additional files (e.g. javascripts, css) along with the requested URL (e.g. an HTML page) to the browser before the browser knows what related files are required, thus saving a round-trip and improve webpage load speed. If the browser already know what resources are needed it can request with normal HTTP calls.
Is there any way to configure Apache to programatically examine a request and cancel the response if the request is invalid. I mean, my intention is to skip responding and just disconnect the client. I'm currently developing a fault-tolerance server fronted by Apache which needs to (stakeholder requirement) ignore answering requests which aren't authorize (I can't even send 401). If I can't use Apache, is there any other way to do it?
Continuation of above comments ...
I dont know how much control you have in JBoss over headers and output sent to the browser, but you can mimic an closed/aborted request like this. From within an application.
Send these Headers, flush and stop all output:
HTTP/1.0 204 No Content
Content-Length: 0
Content-Type: text/html
For example, this is the recommended method the Amazon API suggests as a response to any call that does not want a response.
Setup HTTPS and a redirect from HTTP to HTTPS. Browsing to just the IP address with or without HTTP and HTTPS works great and redirects perfectly. But while browsing to X.X.X.X:443 the web server is displaying the 400 bad request in raw html. Can I either disable the 400 bad request or be able to redirect those requests to HTTPS? Please help. Thanks!
If such is possible, it would depend on which web server you are using and you didn't specify that. However...
Doing so would actually be a bad idea as it would encourage people to use HTTP (no S) to connect to your secure server. In doing so, they would send their request in plaintext. If the system just returned a "301 Moved Permanently" to the HTTPS url, the second request (with reply) would be protected but you still would have leaked the request to a potential attacker during the first attempt.
I need to redirect all requests on port 80 of an application server to a web server. I'm trying to avoid the need to install IIS and instead use WCF to do the job.
It looks like an operation such as the one below is suitable but one problem I've got is if a URL of the form http://mydomain.com/ is used then WCF will present a page about metadata.
[OperationContract, WebGet(UriTemplate = "*")]
RedirectToWebServer();
Does anybody know of a way to get WCF behaving the same as IIS in redirect mode?
This just seems like the wrong tool for the job. If you really don't want to use one of the many web servers that could do this with a couple minutes of setup time (IIS, Apache, Lighttpd), you could just make a simple HTTP socket server.
Listen on port 80. As soon as you get two newlines in a row, send back the response:
HTTP/1.1 301 Moved Permanently
Location: http://myothersite.com/whatever
(I'm almost certain that's the minimum you need). If you want to be really fancy and follow HTTP specs, match HTTP/1.1 or HTTP/1.0 based on what the request has.. but for a quick and dirty redirect, that's all you need.
That said, again, I'd say go grab another web server and set up a redirect using it. There are many lightweight HTTP servers that will work.
Does anyone knows how to tell Apache, in reverse proxy mode, to intercept or trap 302 (or 30x) responses from backend server and redirect internally without sending 30x response back to client?
Ultimately, the backend server the response is redirected to would not be accessible from the outside (or not listed in Apache conf).
My situation:
I have web_server_A and web_server_B listening on port 6666 and 7777. These ports are not accessible from outside, but are accessible from the inside.
I can eventually change the behavior of web_server_A, but not the one of web_server_B.
Apache is listening on ports 80/443, accessible from the outside and is acting as a reverse proxy sending requests addressed to web_server_{A,B}.example.com to web_server_{A,B}
The client asks Apache for web_server_A.example.com/foo. Apache proxies the request to web_server_A which makes some stuff and then sends back to Apache a HTTP/302 response pointing on web_server_B.example.com/bar/secret_token. Apache sends back the 302 response to the client which then sends Apache an HTTP request for web_server_B.example.com/bar/secret_token. Apache proxies the request to web_server_B, which replies something (usually it sends back some big file).
My problem:
I don't want the client to know about the url web_server_B.example.com/bar/secret_token, and ultimately I don't want web_server_B to be accessible from outside.
web_server_A could make the request to web_server_B and then send back the answer from web_server_B without issuing a 302 reply. But, the answer from web_server_B might take some time to come, might be quite big, and web_server_A should not spend too much time on any request (it has no ability for handling big files).
So I thought about a "302 trapper" feature that would be nice if existing, but so far haven't fund anything on the web on how to do that. Any idea?
As a reverse proxy, Apache won't be able to "block replies." It's not a censor.
You could write something like this yourself, though.
using ProxyPassReverse directive, web_server_A will modify Location header sent by web_server_B, so the client won't know about him.
to trap redirect from upstream server you can also edit Location header. For instance "Header unset Location" will show apache default 30X error page