Re: Problems with draft-ietf-http-v11-spec-07

> Replace
>        field-content  = <the OCTETs making up the field-value
>                         and consisting of either *TEXT or combinations
>                         of token, tspecials, and quoted-string>
> with
>        field-content  = <the OCTETs making up the field-value,
>                         either as defined by more specific rules
>                         (see 14, 19.6.2) or *TEXT for unrecognized
>                         message headers>
> Reason:
> The former is unnecessary specific; in fact it seems exactly equivalent
> to
>        field-content  = *(*TEXT | *(token | tspecial | quoted-string) )
> which is apparently not the intention.

Agreed.  However, I think the more appropriate fix would be [in Section 4.2]
to remove field-content (there is no other reference to it) and replace
it with a more accurate definition of field-value, as in
==========

       message-header = field-name ":" *LWS [ field-value ] *LWS CRLF

       field-name     = token
       field-value    = <*OCTET, up to but not including the next line
                         which does not begin with SP or HT>

   Additional requirements may apply to the syntax of each field-value
   according to the definition of the associated field-name.  The common
   HTTP/1.1 header fields are defined in section 14.

   A message-header field with no field-value is considered to have an
   empty or null value.  A header field which does not occur at all as a
   message-header of the message is considered to have no value (a value
   which is undefined) for that message. Depending on the definition of
   a field's semantics, an empty value may or may not be equivalent to
   an undefined value for that field.

   The order in which header fields ...
==========

> Also add after the first paragraph of 3.2, before 3.2.1:
> 
>   Whitespace is not allowed anywhere within an URI.  In other words,
>   the last paragraph of 2.1 (implied *LWS) does not apply to the BNF
>   rules in 3.2.1 and 3.2.2.

I'm not sure if this is wise -- we may wish to allow URI-only header
fields (Location, Content-Location, Content-Base) to be split over
more than one line for use in mail (i.e., ignore any whitespace),
and thus we might be better off with just

   No whitespace is allowed in the Request-URI.

in section 5.1.2.

> In 3.11 Entity Tags, add a sentence somewhere 'Whitspace is not
> allowed between the "W/" prefix and the opaque-tag' (if you think
> it should apply).

Yes.

> In 9.2 [OPTIONS], make the last sentence ("If the OPTIONS request passes
> through a proxy,...") a separate paragraph, to make clear that it
> applies to both preceding pragraphs (which handle "*" and not-"*",
> respectively).

Yes, good catch.  We should also change the second paragraph to say

   Unless the server's response is an error, the response MUST NOT include
   an entity, but MAY include those entity-header fields which describe
   methods, restrictions, or requirements for access to the resource
   (e.g., Allow is appropriate, but Content-Type is not). Responses to
   this method are not cachable.
 
since the existing wording seems to be confusing people.

> 11 Access Authentication, 4th paragraph:
> A user agent that wishes to authenticate itself with a server--usually,
> but not necessarily, after receiving a 401 or 411 response--MAY do so by
>                                               ^^^
> The 411 seems to be in error here.

Yes, that is an error, and it must be a year old.  Crikey.

>> > Comments (within parentheses) should probably allowed in more
>> > places - at least, in 19.4.7
>> >        MIME-Version   = "MIME-Version" ":" 1*DIGIT "." 1*DIGIT
>> > should probably be
>> >        MIME-Version   = "MIME-Version" ":" 1*DIGIT "." 1*DIGIT *comment

Oh, okay.

> Another place where trailing comments could be allowed would be the 
> HTTP From header.  But I don't know how common that is in HTTP/1.0.

No need -- comments are already allowed in the mailbox (from RFC 822).
At least I think that's the case (I can't see my copy of 822 right now).

>> > 10.3.6 305 Use Proxy
>> > 
>> > The requested resource MUST be accessed through the proxy given by the
>> > Location field. The Location field gives the URL of the proxy. The
>> > recipient is expected to repeat the request via the proxy.
>> > 
>> > How exactly does is a proxy "given" by a Location field?
>> > Location normally contains an URI, and URIs point to resources but
>> > not (normally) applications (the proxy).  Does the URI have to be
>> > a http_URL, does the abs_path have to be empty (or is it required
>> > to be "/"), and what if not?
>> 
>> On the contrary, proxies are normally identified by URL.  The URL
>> does not need to be an http URL (though it would be in current practice)
>> and the interpretation of the path (if any) would be dependent on
>> the method of proxying (http would not use any path).
> 
> I don't understand what you mean with "normally".  ...

It is how they were defined (in environment vars) for all WWW clients
prior to Netscape [and any that still use libwww or libwww-perl].

> I understand that you want to keep the spec open for future extensions,
> but since this draft defines (a version of) HTTP, it should at least
> define the use of this header with http_URLs.  Otherwise this response 
> code will be useless (different implementations use it differently,
> or nobody uses it), and it could just as well be defined as
> "This code is reserved for future use" (like 402).

I felt it was self-evident -- you just demonstrated that to be wrong.
We can either change it to "This code is reserved for future use" now
or someone can come up with a complete, yet not too restrictive, definition
of 305 and (as you suggested) Proxy-Location before the editor decides
to generate a new draft.  I won't be able to think about it til Tuesday.
I do consider it *very* important that Proxy-Location not be restricted
to http URLs.

> [1] I don't understand why the spec is so lenient here.  Shouldn't
> all HTTP/1.1 implementations be REQUIRED to recognize all the 
> response codes in this spec?  There are several "client MUST"s
> in other parts for specific response codes, and it's not clear 
> whether "not understanding" a response code lets a client get away
> with not following its MUSTs.  This includes 305.

Yes, the leniency is leftover from HTTP/1.0.  We should add

    HTTP/1.1 clients MUST recognize all of the status codes defined
    by this specification (above).

to the end of the last paragraph in section 6.1.1.

>> > A remark regarding 14.1 Accept:
>> > It's a pity there is a "q=", but not a "mxb=".  An oversight or
>> > intentional?
>> 
>> The conneg group decided it "wasn't needed" based on the observation
>> that browsers didn't implement it.
> 
> There is a way in the latest lynx code to specify it via the .mailcap
> file, and I understand that the Apache server can make use of it.

You should ask Larry if the issue can be reopened and mxb restored.
I personally feel it was a mistake to remove it, and since we have
already missed the boat on getting HTTP/1.1 implemented in the most
recent wave of browsers, we might as well get it right.

 ...Roy T. Fielding
    Department of Information & Computer Science    (fielding@ics.uci.edu)
    University of California, Irvine, CA 92697-3425    fax:+1(714)824-4056
    http://www.ics.uci.edu/~fielding/

Received on Thursday, 22 August 1996 01:54:12 UTC