RE: Opinion on Notify Request Header

Sending those headers involves overhead, a lot of overhead on slower
links. We should have a means of indicating if we want a particular
response stream. I know, I know, its not a proper use of a header. I
agree and am open to suggestions. Where is the balance to be struck?
			Yaron

>-----Original Message-----
>From:	Roy T. Fielding [SMTP:fielding@liege.ICS.UCI.EDU]
>Sent:	Monday, November 04, 1996 11:25 AM
>To:	w3c-dist-auth@w3.org
>Subject:	Re: Opinion on Notify Request Header 
>
>Larry wrote:
>> Oh, so it's a versioning issue, not a client capability issue. That
>> makes sense. Status might be signalled by a
>> 
>>     102 Processing
>> 
>> status code, probably with an entity body which contains the actual
>> status. This would signal the client that the server is still working
>> on the request and not to time out.
>
>Yes, that's one of the reasons why 1xx codes were re-introduced.
>
>> We could add a new request header which indicates a client's
>> willingness to accept such a status code, or else just bundle it in
>> with HTTP/1.2
>> 	  GET uri HTTP/1.2
>> 
>> would be the signal that '102 processing' responses are acceptable.
>
>Unnecessary. Any HTTP/1.1 client must treat all unrecognized 1xx responses
>as if they were 100 responses.  Any client that doesn't is not using
>HTTP/1.1.
>The only thing you have to remind people of is that they can't send or
>forward any 1xx response to an HTTP/1.0 client.
>
>.....Roy (and any implementer that screws-up on that part of the protocol
>          is going to get a severe thrashing from me, since it is the key
>          to status extensibility)
>

Received on Monday, 4 November 1996 17:52:34 UTC