W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 1996

RE: Opinion on Notify Request Header

From: Yaron Goland <yarong@microsoft.com>
Date: Mon, 4 Nov 1996 14:40:55 -0800
Message-ID: <c=US%a=_%p=msft%l=RED-44-MSG-961104224055Z-13744@INET-01-IMC.microsoft.com>
To: "'Roy T. Fielding'" <fielding@liege.ICS.UCI.EDU>, "'w3c-dist-auth@w3.org'" <w3c-dist-auth@w3.org>
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?

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:09 UTC