Re: http progress notification

On 26/05/2010 2:32 a.m., Henrik Nordström wrote:
> tis 2010-05-25 klockan 22:38 +1200 skrev Adrien de Croy:
>> we would only use this if we received a Progress token in the Connection
>> header.  Do you mean some HTTP/1.0 proxies may pass the Connection
>> header on verbatim so pass it on without understanding it?
> HTTP/1.0 did not specify Connection, but that was 1997. Connection have
> been around for 15 years now, and most proxies that announced themselves
> as HTTP/1.0 in 2001 did implement Connection.

OK.  This is quite a difficult issue then, since there are

a) proxies that forward the version of the request even if they aren't 
HTTP/1.1 compliant
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)
c) proxies that don't add via headers.

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.

I don't think we can realistically specify around this.

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

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 think even HTTP/1.0 required intermediaries and clients to support
>> multiple 1xx responses, so this would probably even just work.
> 1xx does not exists in HTTP/1.0. Reserved for future use.


>> Since the interim stage only occurs prior to the actual response (e.g.
>> 200 ok), it's not possible to be buffering an entity at the time you are
>> receiving 1xx messages from upstream.
> What I was thinking about was more in line of how each step along the
> path announces that it will use Progress. It's not very intuitive to the
> end-user if progress indication goes up to 100% and then suddenly drops
> down to 0% again when the next starts processing the response without a
> prior indication that there is more steps to be taken.

OK, that's the reason we added the agent parameter.  If the response 
entity is going through several stages each of which buffer the entire 
entity for processing, there will in fact be several stages of 
spooling.  Each spooling stage can distinguish itself from any other by 
its agent value.

In general though, this will only be a potential issue if several 
chained proxies are poorly connected, otherwise the transfer between 
will be very fast, and the user won't probably notice the updates.

>> So we've discussed here possibly sending the Content-Type (and possibly
>> other headers) through to the client as well, so it can know whether
>> it's downloading something or not, and behave accordingly.   I can't yet
>> think of any requirement for other headers
> Content-Disposition perhaps?
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 

>> but we could perhaps define a way to transport the headers back without
>> making them actual headers of
>> the 1xx response, e.g. prefix header names with X-Orig- or encapsulate
>> them somehow into the Progress response header.  If it were just
>> Content-Type, we'd just put that through as type="..."
> Should be fine to send pretty much any header in 1xx responses, but
> better avoid transport headers such as an Content-Length or
> Transfer-Encoding

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)?

>> Have to also be careful about escaping and charsets for quoted text.
> Agreed, but best if free text is avoided if possible. A token registry
> for states may make sense, and application names should use the same
> product bnf as used for Server.

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.

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

> If there is need for a free text response message then I think it's
> better to add another Progress-Message header for that, defined as TEXT.
> Trying to get implementations to properly quote free text tends to
> always fail in a significant number of implementations.

OK, that's a good idea.



> Regards
> Henrik

Received on Tuesday, 25 May 2010 23:10:28 UTC