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

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).

Cheers,



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