Comments on draft-ietf-http-v11-spec-rev-03

In reading draft-ietf-http-v11-spec-rev-03 I found some revisions
which are potentially damaging.  I'll discuss them below.  I would
like to see these issues resolved before proceeding to draft standard.

- Section 8.2.3:

This section now says:

#  If a user agent sees the transport connection close before it
#  receives a final response to its request, if the request method is
#  idempotent (see section 9.1.2), the user agent SHOULD retry the
#  request without user interaction.

The `befire it receives a final response' is a bit ambiguous, but I
think the most obvious reading is `before it has received the *entire*
final response'.  By contrast, the text in 2068 has the SHOULD in a
much more limited case:

   ...and it sees the connection close
   before receiving any status from the server, the client SHOULD retry
   the request without user interaction....

I don't know if the change from `any status' to `the final response'
was intentional or whether it was an editing mistake.  In any case I
consider the change to be quite dangerous: it requires a fully
compliant user agent to automatically retry, for example, a GET
request yielding a 1 MB response if the connection closes halfway due
to some unusual error condition.  The correct action for the user
agent would be to alert the user of the unusual error.  An automatic
retry could lead to very nasty problem scenarios.

In summary, I want the SHOULD retry condition to be restored to the
one in 2068.

- Section 13.10:

This section introduces a new (as far as I can see) requirement:

#  A cache that passes through requests for methods it does not understand
#  should invalidate any entities referred to by the Request-URI.

This may seem like a good safety measure on the surface but I think
that it is in fact quite damaging.  First, designers of new methods
cannot benefit much from the above rule because 1.0 and 2068 caches
will not adhere to it.  On the other hand, the new rule introduces a
performance penalty for new methods which do not in fact cause any
invalidation.  One such method would be M-GET, a GET extended with a
mandatory extension, for example.  The performance penalty blocks
implied by the new rule makes certain ways of extending the protocol
too expensive and thus shortens the lifetime of the 1.x suite.  I want
the requirement to be removed.


- Section 14.2:

rfc2068 had the sentence

   The ISO-8859-1 character set can be assumed to be acceptable to all user
   agents.

but this sentence has been deleted in the new draft!  I can't remember
that there was any rationale or discussion on the list for deleting
it.  In any case, I think the deletion damages the protocol.  It is
important to specify a charset which is always supported by all
clients, else servers have no reliable way of sending fatal error
diagnostics in text/html entities.  The deletion of the above sentence
also makes the third paragraph in 14.2 slightly nonsensical.

I know that the choice of ISO-8859-1 as the `always supported' charset
has been a subject of contention in the past, but that is no reason to
omit specifying a fallback charset.  If implementation experience has
shown that universally supporting ISO-8859-1 is too difficult, we can
discuss changing the fallback charset to US-ASCII.

In short, the above sentence should be un-deleted.

- Section 14.44:

This section introduces a new (as far as I can see) requirement:

#  The "*" value MUST NOT be generated by a proxy server; it may only be
#  generated by an origin server.

I don't see any reason for having this requirement.  The general rule
should be that transparent proxies may never change or add a Vary
header (this is already implied elsewhere in the spec I believe), and
that non-transparent proxies can do whatever they want.

By the way, proxies which support the TCN protocol extension _will_
sometimes generate "*", this is explicitly allowed by TCN.

In short, the requirement should be deleted.

 - - -

In addition to the above points, I found a potential problem which was
already present in 2068. It looks to me like there is a subtle
requirement on proxies buried in the following text from section 4.4:

# 4.    If the message uses the media type "multipart/byteranges", and
#       the transfer-length is not otherwise specified, then this self-
#       delimiting media type defines the transfer-length. This media type
#       MUST NOT be used unless the sender knows that the recipient can
#       parse it; the presence in a request of a Range header with multiple
#       byte-range specifiers implies that the client can parse
#       multipart/byteranges responses.

As far as I can see, a 1.1 proxy will not delete an existing Range
header field when forwarding a request.  According to the last
sentence above, any 1.1 proxy which forwards a request with a Range
header will be able to parse multipart/byteranges responses.  This
seems to imply that any 1.1 proxy intended for use with
byterange-capable clients will always include code which can parse
multipart/byteranges responses to determine their length.

Was this the original intention?  The start of 14.35.1 seems to imply
otherwise.  Has anybody tried sending a multipart/byteranges response
without chunking and content-length through a 1.1 proxy which does not
support byte range operations?


Koen.

Received on Friday, 27 March 1998 13:01:48 UTC