Comments on the HTTP/1.0 draft.

(By the way, I have not yet succeeded in getting myself subscribed to
this list, so please cc replies to me for the moment.)

Generally, I think the draft of Nov 28 is very good.

Rather egregiously missing is a reference to transmitting network
objects in canonical form.  Section 3.2 should mention this; a
reference to the canonical encoding model in Appendix G of RFC 1521
(specifically step 2) probably should suffice.  The only place this is
hinted at is in the tolerance section of the appendices on tolerance
of broken implementations, but the spec should explicitly say what the
proper behavior is, just in case any servers every actually do that. :-)

As near as I can tell, the spec constrains all header values to be
US-ASCII, meaning nothing that is not US-ASCII may be contained in
them.  We might consider permitting non-US-ASCII information in at
least some headers, probably using RFC 1522's model.

In section 7.5, I don't understand the BNF for the CTE header.  CTE's
don't have subtypes or parameters.

Chuck Shotton said:
>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.

Regarding busy server errors, a "Retry-After:" field might be
reasonable, but I would prefer to just make it an HTTP-date rather
than inventing something new for clients to have to parse.  If we were
going to use relative dates, there are plenty of other places (like
Expires:) where they make as much sense.  A pointer to an alternative
address also seems like a sensible way to handle timeouts.

>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 "+".

I disagree strongly with this interpretation.  A + in search terms
represents a keyword separator, and has nothing to do with a space,
which is (of course) represented as %20.  The fact that some WWW
clients choose to have a space be the device by which the user
communicates keyword separations to the client is irrelevant; it could
just as well be a tab, or a comma, or clicking in a different box.
(The fact that some WWW clients don't allow any way for a keyword to
contain a space reflects a lack of flexibility.)
Marc VanHeyningen  <URL:>

Received on Tuesday, 29 November 1994 11:34:04 UTC