Re: update: http progress notification

OK, so HTTP/1.0 is covered in any case, since 1xx responses are not 
allowed to HTTP/1.0 clients.

That just leaves the issue of whether a client should indicate support 
(or desire) for progress notifications or not.

I'm a little bit reluctant to suggest the progress notifications should 
not require any indication from the client.  If only because some 
clients may want to be able to suppress generation of such messages for 
whatever reason.

So I think my preferred option is a Progress token in the Connection 
header.  That way I don't have to try and dream up something useful in 
terms of parameters for a potential Progress request header.  It also 
means clients that aren't written (e.g. existing clients) to process 
these messages won't receive them for discarding and waste bandwidth 
(esp over slower high-cost circuits such as GPRS / G3 etc).

So, I'll mark up a new I-D for this, proposing 103 as the status which 
appears to be free still in the IANA registry.

Thanks all for your help.

Regards

Adrien


On 28/05/2010 2:37 a.m., Henrik Nordström wrote:
> fre 2010-05-28 klockan 00:18 +1200 skrev Adrien de Croy:
>
>    
>> a) dropping a requirement to suppress these 1xx responses for HTTP/1.0
>> clients
>>      
> That's part of the HTTP specification. Only need to be repeated here in
> text regarding to negotiation support the new response code.
>
>    
>> b) not worrying about semantics of entity headers transported back in a
>> 1xx response.
>>      
> Not sure we need to worry about those, with the exception of
> Content-Length.
>
>    
>> An alternative could be a Progress header in the request, which then
>> would normally be forwarded by proxies.  Then this progress mechanism
>> could work through an HTTP/1.1 proxy that didn't know about it as long
>> as it forwards 1xx responses.
>>      
> Not sure if/how that makes a difference.
>
> Regards
> Henrik
>
>
>

Received on Thursday, 27 May 2010 21:57:19 UTC