Re: status on partitioned drafts

On 14/11/2007, at 11:07 AM, Adrien de Croy wrote:

> I know it shows issue I5 (Via is a MUST) as closed, but this  
> requirement
> sets off many warning bells for me.

As I said previously, those issues aren't quite yet closed in a WG  
sense; now is the time to discuss them.
>
> An intercepting proxy that wishes to maintain transparency can't be
> inserting or modifying any headers at all though.

'transparency' in HTTP is a confusing term, but I know what you mean.

> So, I see several reasons why the Via header is problematic - the main
> one being customer requirements.  I can only really see one reason why
> it could be useful, e.g. to try and debug issues / track down  
> potential
> problems.
>
> Am I missing a bunch of use-cases for the Via header?  Is it  
> expected to
> be used by upstream caches or servers?

Some proxies use it for loop detection, but that's mostly by checking  
to see if their own identifier shows up already. Others embed  
debugging information in the comment.

I've also been able to discover that public sites use accelerators by  
sending TRACE through to the origin server; even though the  
accelerator wasn't configured to send Via on responses, it did on  
requests, and so it shows up in the TRACE response; sort of the  
opposite case of what you're talking about.

> At the moment I'm still strongly inclined to not put it in, or make  
> the
> default setting not to put it in.  It's hard enough getting users  
> to do
> simple things, trying to explain the ramifications of a header like  
> Via
> is a job I'd rather not take on.  Putting a Via header in for  
> responses
> is fine though, just the request side is where I see the major  
> problem.

 From what I've seen, many proxies have a number of settings which,  
when turned on, will cause the proxy to become non-conformant; e.g.,  
see squid.conf. I don't know that there's much we can do about this,  
and I'm not feeling particularly motivated to argue against that  
practice now.

OTOH, making this requirement a SHOULD is probably closer to  
reflecting current practice, especially if we were to have some  
explanatory text about it.


--
Mark Nottingham     http://www.mnot.net/

Received on Wednesday, 14 November 2007 00:28:55 UTC