3 ms·

The issue here is that the frontend may be behind a reverse proxy, talking to the client in HTTPS but to the frontend in HTTP. In that case, the frontend should

by martius 11y ago

The issue here is that the frontend may be behind a reverse proxy, talking to the client in HTTPS but to the frontend in HTTP. In that case, the frontend should probably let the HTTPS header. In practice, with X-Forwarded-Proto, they don't, unless they can authenticate the downstream hop.

jrockway 11y ago
I haven't done web development for a while, but here's how I imagine the frontend server should behave. Let's say you configure your frontend server to set X-Foo and X-Bar fields. First, it should always send a header to the application indicating that it's messing with X-Foo and X-Bar, say "X-Added-By-My-Webserver: X-Foo, X-Bar". That way, the application can be sure that the frontend server is properly configured. Next, it should strip any X-Foo, X-Bar, and X-Added-By-My-Webserver, to prevent the client from being able to confuse the application with information the application expects to receive from the server. This is still flaky because the frontend server could fail, and the user could send X-Added-By-My-Webserver, and so on, but if you must use in-band signalling, this seems like the safe route. Just blissfully adding a header is not enough to protect against evil or changing user agents. Furthermore, it seems like a bad idea to make up your own header and not use an X- prefix.
- martius 11y ago
  Yes, it's a bad idea, but an awful lot of bad ideas were the common practice a long time ago, when vendors had to deal with limitations of the HTTP/1.0 and 1.1 RFCs. In fact, we aren't talking about application headers. The HTTP RFC makes a distinction between application headers and hop-by-hop headers. There are mechanisms that proxies are required to implement, but they still don't. For instance, a proxy must declare itself by appending its signature to a "Via" header - however most of them don't. The RFC about forwarded HTTP extension is unclear about how a hop should deal with those headers, there is no one-size-fit-all situations: http://tools.ietf.org/html/rfc7239#section-8.1 http://tools.ietf.org/html/rfc7239#section-8.1
- ominous_prime 11y ago
  The X- prefix recommendation was deprecated a couple years ago. Since everyone used that format, you had to be careful of collisions anyway. That's not to say you can't use X- to start custom headers, it's just not required.

by martius 11y ago

jrockway 11y ago

I haven't done web development for a while, but here's how I imagine the frontend server should behave. Let's say you configure your frontend server to set X-Foo and X-Bar fields. First, it should always send a header to the application indicating that it's messing with X-Foo and X-Bar, say "X-Added-By-My-Webserver: X-Foo, X-Bar". That way, the application can be sure that the frontend server is properly configured. Next, it should strip any X-Foo, X-Bar, and X-Added-By-My-Webserver, to prevent the client from being able to confuse the application with information the application expects to receive from the server. This is still flaky because the frontend server could fail, and the user could send X-Added-By-My-Webserver, and so on, but if you must use in-band signalling, this seems like the safe route. Just blissfully adding a header is not enough to protect against evil or changing user agents. Furthermore, it seems like a bad idea to make up your own header and not use an X- prefix.

martius 11y ago
Yes, it's a bad idea, but an awful lot of bad ideas were the common practice a long time ago, when vendors had to deal with limitations of the HTTP/1.0 and 1.1 RFCs. In fact, we aren't talking about application headers. The HTTP RFC makes a distinction between application headers and hop-by-hop headers. There are mechanisms that proxies are required to implement, but they still don't. For instance, a proxy must declare itself by appending its signature to a "Via" header - however most of them don't. The RFC about forwarded HTTP extension is unclear about how a hop should deal with those headers, there is no one-size-fit-all situations: http://tools.ietf.org/html/rfc7239#section-8.1 http://tools.ietf.org/html/rfc7239#section-8.1
ominous_prime 11y ago
The X- prefix recommendation was deprecated a couple years ago. Since everyone used that format, you had to be careful of collisions anyway. That's not to say you can't use X- to start custom headers, it's just not required.