Re: update: http progress notification

fre 2010-05-28 klockan 09:56 +1200 skrev Adrien de Croy:

> 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.

A header saying that you do not want notifications perhaps?

But I don't see it likely to be used much, and in those few situations
where I can see it being usedul it can just as well be handled by the
closest proxy with a local policy.

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

It also means that every client which supports this need to add more
overhead to all their requests, plus that existing clients will not
benefit at all from servers supporting progress notifications and will
still suffer from timeouts.

By not requiring negotiation all existing clients will immediately
benefit from the new messages keeping the connection alive, and avoid
clients or network equipment timing out the transaction.

The likelyhood that the progress notifications break existing software
is fairly small, and then only when using software not compliant with
RFC2616 (MUST level requirement to not crash & burn due to unexpected
1xx responses).

Regards
Henrik

Received on Thursday, 27 May 2010 22:25:59 UTC