Round 2: moving HTTP 1.0 to informational

Greetings again. This is the second round of hopefully not-major changes
for the HTTP/1.0 informational draft. Thanks for the comments on the
first round, and I'm glad there were so few: I think we're getting close
to ready. If there is general consensus on these small changes, we're
almost there. A few MIME-concerned people have been working on the
MIME-specific wording, and I'll have that for the WG in a few days in
a separate message.

The changes from the last round are that the addition in 12.5 is longer
and Appendix D is much shorter. The security stuff in 12.5 covers
more general attack. Appendix D is much shorter because much less
detail is given for things that were not implemented widely or
interoperably.

In addition, I've added about half a dozen wording changes to reflect the
fact that this is now informational and not a normative specification. If
there are any objections, we should discuss them, but let's remember
that this is an informational spec about 1.0, not "how the world should
be."

--Paul Hoffman
--Internet Mail Consortium

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

The following paragraph is added after the first paragraph of section 1.1 (Purpose):

   This specification is for informational purposes only. It reflects the
   consensus of the IETF HTTP Working Group about which features would
   normally be found in an HTTP/1.0 implementation. These features are
   split into two sections. The features for which there was strong
   consensus about how they are implemented, as well as implementations
   of the features, are listed in the main body of this document.
   Features for which there was not strong consensus, or for which there
   were few implementations, are listed in Appendix D.

After the third chain diagram in section 1.3, ("Not all responses..."), I'd
like to change the second sentence to read:

   Some HTTP/1.0 applications use heuristics to describe what is or is
   not a "cachable" response, but these rules are not standardized.

Two paragraphs later, ("Current practice requires that the
connection..."), I'd like to allow for the experimental keep-alive
work and say:

   Except for experimental applications, current practice requires...

Also in the next sentence, I'd like to change "Both clients and
servers must be capable..." to:

   Both clients and servers should be aware that either party may close
   the connection prematurely, due to user action, automated time-out,
   or program failure, and should handle such closing in a predictable
   fashion.

In section 3.5, in the descriptions of x-gzip, remove "Gzip is available
from the GNU..." and the URL, since these might not be long-lasting
information.

At the end of 8.3, I'd like to change "Applications must not cache
responses to a POST request." to:

   Applications must not cache responses to a POST request because the
   application has no way of knowing that the server would return an
   equivalent response on some future request.

At the end of Section 10.15, add:

   Note: Some existing servers fail to restrict themselves to the product
   token syntax within the Server field.

At the end of Section 10.16, add:

   Note: Some existing clients fail to restrict themselves to the product
   token syntax within the User-Agent field.

Section 12.5 is added:

12.5  Attacks Based On File and Path Names

Implementations of the HTTP servers should be careful to restrict the
documents returned by HTTP requests to be only those that were intended
by the administrators. If an HTTP server translates HTTP URIs directly
into file system calls, the server must take special care not to serve
files that were not intended to be delivered to HTTP clients. For
example, Unix, Microsoft Windows, and other operating systems use ".."
as a path component to indicate a directory level above the current one.
On such a system, an HTTP server must disallow any such construct in the
Request-URI if it would otherwise allow access to a resource outside
those intended to be accessible via the HTTP server. Similarly, files
intended for reference only internally to the server (such as access
control files, configuration files, and script code) must be protected
from inappropriate retrieval, since they might contain sensitive
information. Experience has shown that minor bugs in such HTTP server
implementations have turned into security risks.

Appendix D is added:

D.  Additional Features

This appendix documents features which were was not strong consensus in
the IETF HTTP Working Group, or for which there were not a sufficient
number of interoperable implementations. In some cases, there was strong
consensus that the feature was needed but disagreement about how it
should be implemented. In other cases, there was no general agreement on
the feature. Implementors who add the features in the Appendix should be
aware that software using these features are less likely to be
interoperable than software using the features from the main part of
this specification.

The specifications in this section are shorter than they were in earlier
drafts of the HTTP 1.0 specification. Some implementions of the features
in this appendix are based on fuller descriptions of the features.

D.1 Additional Request Methods

D.1.1 PUT

The PUT method requests that the enclosed entity be stored under the
supplied Request-URI. If the Request-URI refers to an already existing
resource, the enclosed entity should be considered as a modified version
of the one residing on the origin server. If the Request-URI does not
point to an existing resource, and that URI is capable of being defined
as a new resource by the requesting user agent, the origin server can
create the resource with that URI.

The fundamental difference between the POST and PUT requests is
reflected in the different meaning of the Request-URI. The URI in a POST
request identifies the resource that will handle the enclosed entity as
an appendage. That resource may be a data-accepting process, a gateway
to some other protocol, or a separate entity that accepts annotations.
In contrast, the URI in a PUT request identifies the entity enclosed
with the request -- the user agent knows what URI is intended and the
server must not attempt to apply the request to some other resource.

D.1.2 DELETE

The DELETE method requests that the origin server delete the 
resource identified by the Request-URI.

D.1.3 LINK

The LINK method establishes one or more Link relationships between 
the existing resource identified by the Request-URI and other 
existing resources.

D.1.4 UNLINK

The UNLINK method removes one or more Link relationships from the 
existing resource identified by the Request-URI.

D.2  Additional Header Field Definitions

This section defines the syntax and semantics of all standard 
HTTP/1.0 header fields. For Entity-Header fields, both sender and 
recipient refer to either the client or the server, depending on 
who sends and who receives the entity.

D.2.1  Accept

The Accept header field can be used to indicate a list of media 
ranges which are acceptable as a response to the request. The 
asterisk "*" character is used to group media types into ranges, 
with "*/*" indicating all media types and "type/*" indicating all 
subtypes of that type. The set of ranges given by the client should 
represent what types are acceptable given the context of the 
request.

D.2.2  Accept-Charset

The Accept-Charset request header field can be used to indicate a 
list of preferred character set encodings other than the default
US-ASCII and ISO-8859-1. This field allows clients capable of 
understanding more comprehensive or special-purpose character set 
encodings to signal that capability to a server which is capable of 
representing documents in those character set encodings.

D.2.3  Accept-Encoding

The Accept-Encoding request header field is similar to Accept, but 
restricts the encoding-mechanism values which are acceptable in the 
response.

D.2.4  Accept-Language

The Accept-Language request header field is similar to Accept, but 
restricts the set of natural languages that are preferred as a 
response to the request.

D.2.5  Content-Language

The Content-Language field describes the natural language(s) of the 
intended audience for the enclosed entity. Note that this may not 
be equivalent to all the languages used within the entity.

D.2.6  Link

The Link header provides a means for describing a relationship 
between the entity and some other resource. An entity may include 
multiple Link values. Links at the metainformation level typically 
indicate relationships like hierarchical structure and navigation 
paths.

D.2.7  Retry-After

The Retry-After response header field can be used with a 503 
(service unavailable) response to indicate how long the service is 
expected to be unavailable to the requesting client. The value of 
this field can be either an HTTP-date or an integer number of 
seconds (in decimal) after the time of the response.

D.2.8  Title

The Title header field indicates the title of the entity.

D.2.9  URI

The URI-header field may contain some or all of the Uniform 
Resource Identifiers (Section 3.2) by which the Request-URI 
resource can be identified. There is no guarantee that the resource 
can be accessed using the URI(s) specified.

Received on Monday, 8 January 1996 11:35:45 UTC