Re: A few semantic points for HTTP/1.0 draft

Chuck Shotton writes:

> As a solution, I'd like to propose an additional response-header for the
> 503 error response that specifies a time at which the client may expect the
> server to be able to handle requests again. This time should be relative to
> the Date: header sent by the client. I propose that this time be specified
> as a delta from this date in terms of hours, minutes, and seconds until
> availability. The client should not attempt to resend its request before
> this delta period of time has elapsed.

Yes.  In fact, Henrik had proposed the same while we were in the process
of writing it, but it didn't find its way into the spec.  The problem was
was that neither of us were sure of what the format should be, and I see
from the ensuing discussion on this list that others are having that problem
as well.

The way I see it, there are three viable options:

   Retry-After    = "Retry-After" ":" delta-seconds
or 
   Retry-After    = "Retry-After" ":" HTTP-date
or
   Retry-After    = "Retry-After" ":" delta-seconds / HTTP-date
where
   delta-seconds  = 1*DIGIT

There is no point in dealing with milliseconds -- that level of accuracy
is just not necessary.  Also, the reason for the delay can be explained
via the Reason-Phrase on the Status-Line or in the object body (if any)
returned by the error response.

> For the case of a busy server, this could be a delta of a few seconds from
> the present (or a delta value calculated on the load of the server, depth
> of the request queue, etc.)

Yes, and that is most efficiently handled by a delta-seconds -- formatted
dates are very expensive to parse.

>                             For an "off-line" server, this could be a delta
> supplied by administration (i.e. the server will be back up in 30 minutes)
> or an arbitrarily longer value (10 seconds, a few minutes) that would
> prevent rapid client retries.

Yes, and that is why a formatted date would be nice.  I would not make this
a delta, since large time deltas are hard for people to grok.
Perhaps the third alternative is best then, since it is trivial for
the receiver to differentiate between an HTTP-date and a delta-seconds.

Comments?


> With regard to comment number 2, the encoding of object-body parts, there
> is a non-trivial ambiguity in RFC 1630 regarding the encoding of spaces as
> "+", and where this is allowed. For WWW clients that encode object-bodies
> using the URL-encoding scheme, behavior is inconsistent. Some clients
> encode specials in the object-body text using %xx hex encodings
> exclusively. Others use %xx encodings for all specials except space, and
> encode spaces as "+".
> 
> According to 1630, "+" may be used as a shorthand for space in the search
> portion of a URI. Unfortunately, the BNF for URIs is ambiguous in that the
> definition of the non-terminal "xpalphas" includes separating "xalphas"
> with "+", implying that spaces can be encoded as "+" anywhere.

No, actually that only indicates that "+" is allowed in http URI path segments.
In the path, the "+" should never be interpreted as a space.

> In my opinion, the object-body of a HTTP request is not the search portion
> of a URI. Therefore, spaces should only be encoded using %xx encodings and
> not "+" encodings. This ambiguity has never been resolved and a definitive
> statement regarding appropriate encoding of object-bodies using
> URL-encoding in this draft of the HTTP standard would be helpful. It may be
> a moot point, since many clients encode POST arguments using both
> techniques, and many gateway apps parse pluses as space. Nonetheless, an
> appropriate "ruling" should be made in the HTTP standard.

Yes, good point.  Since the IETF URL spec does not itself give a full
specification of HTTP URLs, it will probably have to be included here
so that the URL RFC can eventually include a proper reference.
One problem then is how to handle the conflict between WWW URI's and
IETF URLs.

On the other hand, somebody (perhaps the HTML-WG) may wish to define
the application/www-url-encoded-form as a real media type for use in other
protocols, in which case it should not be in the HTTP spec.
Does anyone think that is likely?  It seems unlikely to me that anyone
would want to standardize a hack like that.


......Roy Fielding   ICS Grad Student, University of California, Irvine  USA
                                     <fielding@ics.uci.edu>
                     <URL:http://www.ics.uci.edu/dir/grad/Software/fielding>

Received on Wednesday, 30 November 1994 01:03:31 UTC