RE: Opinion on Notify Request Header

I suspect this is hair spliting but my understanding of "100 Continue"
is that it is meant to be sent while a request message is being
transmitted to indicate to the client that the request is being properly
received. Further, I thought that if the request has completed
transmission then all "100 Continue"s should be thrown out. I thought it
was introduced because of chunking.

What I am suggesting is that the server will send a continuous stream of
update messages, which will be formatted as responses, informing the
client of a request's progress. This would be used to create progress
bars and the like. If we wanted I am sure "100 Continue" could be tasked
to the purpose, we just need to make sure that each response contains
enough context so the client can unambigously determine which request
the response is in reference to.

This sort of asynchronous notification solves a problem so fundamental
it has been built into just about every OS known to humanity.

				Yaron

>-----Original Message-----
>From:	Larry Masinter [SMTP:masinter@parc.xerox.com]
>Sent:	Sunday, November 03, 1996 9:15 PM
>To:	ejw@ics.uci.edu
>Cc:	w3c-dist-auth@w3.org
>Subject:	Re: Opinion on Notify Request Header
>
>Now that I've read the draft, I have to confess that I don't
>understand what you intended to do with the Notify Request Header.
>
>Is this a way of the client asking "please send me 100 Continue
>messages as you're progressing?" Or did you intend for some other kind
>of progress report to be sent back?
>
>I see no value in a 'please notify me' request header. Clients will
>ignore 100 Continue messages if they aren't going to process them
>specially. And any client that is WILLING to process 100 Continue
>messages would always be asking for them.
>
>In general, I suggest that you avoid adding any features whose value
>you're not sure of, unless it solves a well known and widespread
>problem.
>
>Larry
>
>
>
>
>

Received on Monday, 4 November 1996 00:45:34 UTC