Re: Proposal for new HTTP 1.1 authentication scheme

On Tue, 9 Dec 1997, Dave Kristol wrote:

> 
> Ummm...  I think my "MUST -> SHOULD" had to do with a proxy's changing
> the content of headers.  

Sorry, my mistake.

> I think I see the words to which you're
> referring (end of p.13), and they mention Content-Length explicitly but
> don't mention Date.  And there's a potential problem with
> Content-Length:  suppose a proxy eats chunked data and wants to create a
> complete entity *with* Content-Length.  Is it hereby forced to forward
> the entity as "chunked" because it's forbidden to add Content-Length?
> 
  ...snip..

> I agree it's a dilemma.  An option is to require that clients send
> Content-Length and (perhaps) not Date, and forbid proxies to add either
> within this context.
> 

Here is what the spec says:

       The entity-info elements incorporate the values of the URI used
       to request the entity as well as the associated entity headers
       Content-Type, Content-Length, Content-Encoding, Last-Modified,
       and Expires. These headers are all end-to-end headers (see
       section 13.5.1 of [2]) which must not be modified by proxy
       caches. The "entity-body" is as specified by section 10.13 of [2]
       or RFC 1864. The content length MUST always be included. The
       HTTP/1.1 spec requires that content length is well defined in all
       messages, whether or not there is a Content-Length header.

I was remembering "which must not be modified by proxy caches" as
"which MUST NOT be modified by proxy caches."

I guess I don't see a problem with this.  On the question of length it
says the content length must be used in the digest even if there is no
Content-Length header.  This seems fine and should cause no problem if
a proxy unchunks a chunked response.  The server has to calculate the
MD5 digest of the entity so it will not be much harder to calculate
the length.  I guess the proxy better get the length right or the
client better do its own length calculation and not trust the proxy.

As for Date, I guess the only problem is servers with no clock.
They don't send a Date header.  Draft-v11-rev01  says 

       A received message that does not have a Date header field MUST be
       assigned one by the recipient if the message will be cached by that
       recipient or gatewayed via a protocol which requires a Date.

So it seems that it is fine for the proxy to forward the dateless
response as long as it does not cache the entity.  It is unlikely
that an authenticated response should be cached anyway.

Maybe there are problems I don't understand.

John Franks
john@math.nwu.edu

Received on Tuesday, 9 December 1997 14:05:47 UTC