Re: site-wide headers

I agree that this is a benefit that it picks up all the warts and
wrinkles that come with using HTTP header fields.  I just wanted to
make clear that this isn't 100% positive.

On 1 October 2016 at 16:12, Willy Tarreau <w@1wt.eu> wrote:
> Hi Martin,
>
> On Wed, Sep 28, 2016 at 09:00:05PM +1000, Martin Thomson wrote:
>> (https://tools.ietf.org/html/draft-nottingham-site-wide-headers-00)
>>
>> I like this approach because it is more obviously composable into an
>> existing system at the consuming end.  I especially like that the
>> format is without opinion about its contents.  That makes it quite
>> powerful.
>>
>> I dislike this approach (in contrast to the JSON-based
>> origin-policy[1]) because it uses header fields.  Of course that makes
>> it better suited to HTTP.
>
> In fact that's what I find powerful here. I know *many* places where
> these headers are set by the front reverse-proxy, simply because it
> ensures that they're uniform across all the servers. But it also
> happens that there are exceptions (eg: for static some servers or
> certain unrelated applications). With this mechanism, there's almost
> nothing to change in the way it works. The admin will just have to
> add "HS" to the responses instead of adding all these header fields,
> when the reverse-proxy notices that the client provided the valid SM
> field. And it also ensures the proxy an simply remove HS: and replace
> it with all appropriate headers when it comes from a server where it's
> not appropriate at all (you know, some application developers like to
> copy-paste when they don't know).
>
> So in fact, it supports everything already supported today but the
> smarter way. It's really nice in my opinion.
>
> Cheers,
> Willy

Received on Saturday, 1 October 2016 07:27:45 UTC