HTTP/1.0 Issues

Something to think about on the plane to Boston ....

The HTTP-WG meeting will take place at 1530-1730 on MONDAY, April 3, 1995
It will be broadcast on the MBONE.

     5 mins -- Overview of charter, and changes to agenda

    10 mins -- Progress on HTTPng

    10 mins -- Status of HTTP/1.0 spec
    20 mins -- discussion of outstanding issues regarding HTTP/1.0

    10 mins -- Overview of HTTP/1.1
    10 mins -- Digest Access Authentication
    10 mins -- Mediated Digest Authentication
    45 mins -- Further discussion of what should (not) be in HTTP/1.1

That doesn't give us a lot of time, but I guess the important things
will happen in the hallways anyway.

=========================================================================
Here's what I have for outstanding issues on the HTTP/1.0 draft:

    Write section about URI
    Write appendices on minimum compliance

    Status section: Fix mailing list address (www-talk@mail.w3.org)

    3.1 HTTP Version: "understand requests with a format within one major
        number" *less than or equal to their* "native major version".

    3.3.1 Full Date: Only proxies need to support the asctime() date format.
        Make "robust date handling" a note, with additional explanation.

    4.2 Message Headers: Needs a clear statement on multiple fields,
        something like "duplicate header fields are only allowed where
        mentioned explicitly, and their use is discouraged".

    4.3.2: Forwarded: The final sentence about hiding internal hosts should
        say that existing Forwarded headers (added by proxies inside the
        firewall) should be removed.

    4.3.3 Message-ID: Allow applications to send Message-ID if they have
        a good reason for doing so.  Or should we move it into Entity
        headers? Message-ID causes confusion because of the spec's
        definition of "message" -- perhaps we just need to clarify the
        difference.

    5.2.3 POST: "(usually a form)" should be ", such as the result of
        submitting an HTML form,". Must include a valid Content-Length
        for HTTP/1.0 POST requests.

        What to do when a redirect is received from a POST?
        Current practice seems to be that the client issues a GET
        request to the new address.

    5.2.4 PUT: Must include a valid Content-Length for HTTP/1.0 PUT requests.

    5.4.1 Accept:

        Remove the notion of "unusual types".

        Should the q value of */* default to 0.5?
        This would make things easier on backward compatibility issues,
        and has no affect on proper use of the algorithm.

        If a browser explicitly uses q=0 on a specific type, e.g.,

           Accept: application/octet-stream; q=0, application/*;q=0.5

        then that specific type is explicitly disallowed in spite of the
        existance of the more general "application/*;q=0.5".

    5.4.2 Accept-Charset: remove extra "." on end of Note.

    5.4.6 From: "addr-spec" should be replaced with "mailbox in RFC 822
        (as updated by RFC 1123)." and same change to BNF.

    6.1 Status-Line: last para, remove "considered" and strenghten last
        sentence.

    6.2.3 407 Proxy Authentication Required: delete " -- this feature ..."

    6.3.1 Public: should say "applies only for the nearest neighbor in a
        connection chain" (i.e., the closest server),
        rather than applies only to the current connection".

    6.3.2 Retry-After: first para, nix "full".

    7.1: Remove note about future use of HTML metainfo names.

    7.1.1 Allow: Not allowed on POST requests.  With PUT, Allow would be an
        entity-header specifying the methods to be supported.  In a 405
        response, Allow is metainformation about the resource identified
        by the Request-URI, it is not metainformation about the entity-body
        in the response. Add cross-reference to Public header.

    7.1.9 Last-Modified: replace "last-mod date." with "last-modify time."

    7.1.11 Location: Make a legitimate field (and can serve as the default
        URI if URI-header is not given). 

    7.1.13 URI: URI must be required for request URLs subject to
        content negotiation variants.  Should "qs" be given as well?

    7.1.14 Version: "A user agent can request a particular version of an
        entity by including its tag in a Version header as part of the
        request" should only refer to non-content requests (GET and HEAD).

    7.2.2 Length: HTTP/1.0 POST and PUT must include a valid Content-Length.
        I've given up any notion of having the end-of-entity indicated by
        the media type -- it would require the server to indicate acceptance
        of that type.  Add sentence to the effect that if Content-Length
        is not specified on a request, and the server does not recognize or
        cannot calculate the length from other fields, then 400 Bad Request
        may be returned.

    8.1.1 Canonicalization: last para, "HTTP does not require that ..."
        should be replaced with:
       "It is recommended but not required that the character set of an 
        entity body be labelled as the lowest common denominator of the
        character codes used within a document, with the exception that
        no label is preferred over the labels US-ASCII or ISO-8859-1."

    8.2 Language Tags: description needs to state that they imply
        hierarchy, e.g.:

           In the context of the Accept-Language header (section 5.4.4) a
           language tag is not to be interpreted as a single token, as per
           RFC 1766, but as a hierarchy.  A server should consider that
           it has a match when a language tag received in an Accept-Language
           header matches the initial portion of the language tag of a
           document.  An exact match should be preferred.  This
           interpretation allows a browser to send, for example:
     
             Accept-Language: en-US, en
     
           when the intent is to access, in order of preference, documents
           in US-English ("en-US"), 'plain' or 'international' English
           ("en"), and any other variant of English (initial "en-").

    8.5 Transfer Encodings: Define what "safe transport" means for HTTP
        and add a note about future use of packetized transfer encodings.

    9. Content Negotiation: 

        We need an automatable subset of HTML to act as the response
        content for 300 and 406 responses.  This would be a mini-URC.

        Do we need guidelines on how to assign qs on the server?

        Should we add a "ql" parameter to the Accept-Language header
        and multiply this in with the other quality factors?

        The browser should be able to indicate that it will accept */*, 
        but if different versions exist, it specifically _wants_ a
        "300 Multiple Choices" response (if you have more than one version,
        let me see what you have).
    
        A browser should be allowed to specify a preference for certain 
        "usual" media types without the user configuring it to do so.

        Replace "ANSI C floating point text representation" with:

           float = ( "0" [ "." 0*3DIGIT ]
                   |     ( "." 0*3DIGIT )
                   | "1" [ "." 0*3("0") ] )

    10. Access Authentication: Verify that the terms "authorization"
        and "authentication" are being used correctly (I think they are).

    Globally replace all "i.e. " and "e.g. " with "i.e.," and "e.g.,"
       and other minor nits.

    If possible, move appendix C to individual notes.

=========================================================================

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

Received on Friday, 31 March 1995 11:35:36 UTC