W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2014

Re: Expiration impending: <draft-nottingham-http-patch-status-00.txt>

From: Mark Nottingham <mnot@mnot.net>
Date: Mon, 15 Sep 2014 15:20:30 -0400
Cc: Martin Thomson <martin.thomson@gmail.com>, "Buzonas, Steve" <sbuzonas@carnegielearning.com>, "Julian F. Reschke" <julian.reschke@gmx.de>, HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <17D47AED-F586-4317-B3C4-49101D4286E6@mnot.net>
To: Poul-Henning Kamp <phk@phk.freebsd.dk>
Ideally, the patch format would carry something to do that. If not, wed need some external means of verifying it (such as one of the various hash / signature mechanisms under discussion); the trick is to make sure what the hash/sig is applied to is clear.

The other thing to think about when creating a patch format, btw, is whether the patch can manipulate stored HTTP headers; it might be worth coming up with some generic way to do that too (tho itd be a bit ugly, I suspect, if its carried in headers).


On 12 Sep 2014, at 10:41 am, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote:

> --------
> In message <CABkgnnWgA+cTwUcxF_kt1SQsmEz5X4=82G=do+3Vxtg24NaxZw@mail.gmail.com>
> , Martin Thomson writes:
>> On 11 September 2014 22:51, Buzonas, Steve
>> <sbuzonas@carnegielearning.com> wrote:
>>> Passing an MD5 sum won't really cut it either. Each hop could replace the value with whatever it decides to tack on.
>> I think that the concern is accident here, not malice.
> That's my concern:  How does the client know it got the right post-patch
> result ?
> -- 
> Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
> phk@FreeBSD.ORG         | TCP/IP since RFC 956
> FreeBSD committer       | BSD since 4.3-tahoe    
> Never attribute to malice what can adequately be explained by incompetence.

Mark Nottingham   http://www.mnot.net/
Received on Monday, 15 September 2014 19:20:56 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 30 March 2016 09:57:10 UTC