Re: http progress notification

ons 2010-05-26 klockan 11:09 +1200 skrev Adrien de Croy:

> a) proxies that forward the version of the request even if they aren't 
> HTTP/1.1 compliant

Broken proxy. Not even allowed by HTTP/1.0.

> b) proxies that don't strip headers based on Connection header tokens 
> nor alter the Connection header but advertise themselves as HTTP/1.1 
> compliant (e.g. only support Keep-alive)

Broken proxy. HTTP/1.1 is very clear on Connection.

> c) proxies that don't add via headers.

Also broken.

> So it will be possible for a server to receive an HTTP/1.1 message with 
> Connection: Progress in it, even though the sender of the message 
> doesn't understand progress.

It's possible for a server to receive anything.

It's not realistic to try to work around every broken piece of software
there is out there.

The case I am talking about is purely mismatch between HTTP/1.0 and 1.1.
Not broken software.

> However excluding Progress from responses to HTTP/1.0 messages does seem 
> prudent.

Personally I am not sure it needs to be mentioned for the reasons given
before. The amount of proxies in use today and not supporting Connection
SHOULD be minimal.

> Also, given the amount of time it takes to roll out things like this, I 
> imagine the incidents of proxies behaving like this in say another 10 
> years will be low.

I argue that it's already low, and should be close to distinct in
another 10 years.


> I wondered about that.  It's not a common header, and I don't know of 
> any browsers that use it to make a handling decision instead of 
> Content-Type.

Every browser I tried..

> OK, that could be quite good, then a downstream proxy can make policy 
> decision based on content type etc as early as possible.
> 
> So it's not in violation to send entity headers when there can be no 
> entity (in a 1xx response message)?

I do not think so. Especially not with this being a hop-by-hop
negotiated feature.

> I thought about that too, but the target for the text in the agent value 
> (only currently proposed text field) is a human, and so I thought it 
> would be preferable not to include things like version numbers etc etc.

I disagree, for the exact same reason those are in Server. The agent
name is mostly for diagnostic purposes, not to be human friendly.

> So the intention was just a simple label.  More like a realm for auth.  
> Something the human will hopefully recognise (or learn to).

which is not an agent description, but more like a state description.

Regards
Henrik

Received on Tuesday, 25 May 2010 23:38:53 UTC