W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2008

Re: i28 proposed replacement text

From: Julian Reschke <julian.reschke@gmx.de>
Date: Tue, 03 Jun 2008 19:23:30 +0200
Message-ID: <48457E12.1020101@gmx.de>
To: Jamie Lokier <jamie@shareable.org>
CC: Henrik Nordstrom <henrik@henriknordstrom.net>, Yves Lafon <ylafon@w3.org>, Joe Orton <joe@manyfish.co.uk>, Mark Nottingham <mnot@mnot.net>, Brian Smith <brian@briansmith.org>, ietf-http-wg@w3.org

Jamie Lokier wrote:
> Henrik Nordstrom wrote:
>> Integrity is not a property of the transport. The transport is
>> hop-by-hop and must only guarantee internal consistency, allowing
>> unambigious parsing of the data stream. Integrity checks should be done
>> at the message level.
> True, but there is no practical mechanism in HTTP at the moment to
> assure even the most basic message integrity: that you received all of it.
> Content-MD5 is not useful for dynamically produced entities.
> As a trailer it might be possible, but how compatible is that?

Well, unless I'm missing something, it will be hard to send from a 
servlet (hey, Servlet EG, are you listening...?).

> Content-Length, even, cannot be used.
> Not even for static content.  When the server does provide
> Content-Length, in your own example the proxy->client hop removes
> Content-Length.
> I'm thinking that the solution to these is allowing Content-Length in
> a chunked trailer, and Content-MD5 too.

Well, what would they contain in case of a truncated response? Surely 
not the length/digest of the actual response, because that wouldn't help 
the client finding out about the truncation...

Maybe something like "final-status" as a new response header would make 
sense. That way, a server could send an initial 2xx, start sending 
content, and in case of internal errors could at least signal that 
something went fatally wrong...

BR, Julian
Received on Tuesday, 3 June 2008 17:24:13 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:46 UTC