W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2010

Re: update: http progress notification

From: Henrik Nordström <henrik@henriknordstrom.net>
Date: Thu, 27 May 2010 13:04:31 +0200
To: Adrien de Croy <adrien@qbik.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <1274958271.4945.15.camel@henriknordstrom.net>
ons 2010-05-26 klockan 14:09 -0700 skrev Roy T. Fielding:

> No.  There is nothing wrong with the recipient doing other things,
> like maintaining a sidebar with logs or displaying the status
> briefly in some status area.  The fact that it isn't ignored does
> not imply that the recipient keels over or explodes.

Fair enough.

Just got a little confused about 101 which clearly must not be ignored
even if the client doesn't know about 101, and the implications of that
on introduction of new 1xx status codes.

But somehow I overlooked the first part of the same paragraph. "A client
MUST be prepared to accept one or more 1xx status responses prior to a
regular response" which covers things nicely, and the oddness of 101 is
covered by other means (Connection). We may want to clarify that to add
"or other" in the part that mentions "expect a 100"....

So no negotiation is really needed for the use of a Progress status, and
servers MAY send Progress notifications whenever they deem it's good as
long as general 1xx requirements is fulfilled. In many cases it would
help even clients without Progress support as it keeps the connection
alive avoiding timeout.

If it's found that there is clients failing due to progress notification
and getting those fixed is not an viable option then administratively
configuring the server or proxy with a blacklist is imho the best
solution to the "negotiation" problem.

Received on Thursday, 27 May 2010 11:05:09 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:53 UTC