21–30 of 39 posts
Hmm... I've worked on software at three different orgs that rely on the X-Forwarded-For header to identify a client's IP address from in front of a firewall (I'm not a network guy, but I think it was Cisco equipment). I agree the X- prefix ain't great. Is there an alternative for the originating IP address? If not, we need one.
I guess django will have to find a replacement for X-CSRFToken
X-Ua-Compatible: IE=Edge,chrome=1
X-Request-Id: 19c0a05fd28e371127a76f658203eace
X-Runtime: 0.002039
X-Content-Digest: 2c4b5e9fc815a69ecb514e41e27e6ac7f2716801
X-Rack-Cache: miss, store
X-Varnish: 1299462197
X-Cache: Hit from cloudfront
X-Amz-Cf-Id: kDpGVcaIcDVQm-PkMd_FPnR_IcPZqPgR0NxKEvmOBWKaURpeus5vEw==,_ycCBrLJT91EOYt14GTciFKKLlpzLt1cogvPpK2PkDP7QzYVGbcsGQ==
What is wrong with custom http headers? Like these from Cloudfront: X-Ua-Compatible: IE=Edge,chrome=1 X-Request-Id: 19c0a05fd28e371127a76f658203eace X-Runtime: 0.002039 X-Content-Digest: 2c4b5e9fc815a69ecb514e41e27e6ac7f2716801 X-Rack-Cache: miss, store X-Varnish: 1299462197 X-Cache: Hit from cloudfront X-Amz-Cf-Id: kDpGVcaIcDVQm-PkMd_FPnR_IcPZqPgR0NxKEvmOBWKaURpeus5vEw==,_ycCBrLJT91EOYt14GTciFKKLlpzLt1cogvPpK2PkDP7Q…
The primary problem with the "X-" convention is that unstandardized
parameters have a tendency to leak into the protected space of
standardized parameters, thus introducing the need for migration from
the "X-" name to a standardized name. Migration, in turn, introduces
interoperability issues (and sometimes security issues) because older
implementations will support only the "X-" name and newer
implementations might support only the standardized name. To
preserve interoperability, newer implementations simply support the
"X-" name forever, which means that the unstandardized name has
become a de facto standard (thus obviating the need for segregation
of the name space into standardized and unstandardized areas in the
first place).
In some situations, segregating the parameter name space used in a
given application protocol can be justified:
1. When it is extremely unlikely that some parameters will ever be
standardized...
2. When parameter names might have significant meaning...
3. When parameter names need to be very short (e.g., as in [RFC5646]
for language tags)...What is wrong with custom http headers? Like these from Cloudfront: X-Ua-Compatible: IE=Edge,chrome=1 X-Request-Id: 19c0a05fd28e371127a76f658203eace X-Runtime: 0.002039 X-Content-Digest: 2c4b5e9fc815a69ecb514e41e27e6ac7f2716801 X-Rack-Cache: miss, store X-Varnish: 1299462197 X-Cache: Hit from cloudfront X-Amz-Cf-Id: kDpGVcaIcDVQm-PkMd_FPnR_IcPZqPgR0NxKEvmOBWKaURpeus5vEw==,_ycCBrLJT91EOYt14GTciFKKLlpzLt1cogvPpK2PkDP7Q…
Hmm... I've worked on software at three different orgs that rely on the X-Forwarded-For header to identify a client's IP address from in front of a firewall (I'm not a network guy, but I think it was Cisco equipment). I agree the X- prefix ain't great. Is there an alternative for the originating IP address? If not, we need one.
Well, I guess their hope is that people start using Forwarded-For, and then it becomes standardized in the same way that X-Forwarded-For has sort of become standard.
Hmm... I've worked on software at three different orgs that rely on the X-Forwarded-For header to identify a client's IP address from in front of a firewall (I'm not a network guy, but I think it was Cisco equipment). I agree the X- prefix ain't great. Is there an alternative for the originating IP address? If not, we need one.
> 1. Deprecates the "X-" convention for newly defined parameters (emphasis mine)
> 4. Makes no recommendation as to whether existing "X-" parameters ought to remain in use or be migrated to a format without the "X-"; this is a matter for the creators or maintainers of those parameters.
In practice, I expect X-Forwarded-For to live long and prosper for many years even if a X-less version standardizes.
Good thing. Next, please convince browser vendors to support HTTP methods (PUT, DELETE, etc.) in forms.
Good thing. Next, please convince browser vendors to support HTTP methods (PUT, DELETE, etc.) in forms.
You're probably aware of this, but for those that are not, you can easily get around this problem by adding a hidden form field with X-HTTP-Method-Override as the name and the method as the value. Assuming your web server supports the field.
Earlier quoted context omitted.
You're probably aware of this, but for those that are not, you can easily get around this problem by adding a hidden form field with X-HTTP-Method-Override as the name and the method as the value. Assuming your web server supports the field.
Awesome, I don't know if I'll ever use it, but it's good to know.