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

From: Mark Nottingham <[email-masked]>
Date: Thu, 11 Sep 2014 15:27:45 +0200

<http://tools.ietf.org/html/draft-nottingham-http-patch-status-00>

Just curious, what do people think about this? 

There are a few different use cases, including:

* Doing it for updates to “normal” Web content — this would require both browser (or proxy) support as well as the server to track the diffs between what’s deployed. The former can come in time, but the latter is operationally difficult; it’s possible, but would take a fair amount of discipline (and some way for admins/devs to interact with the server to use this; not sure what that would look like yet).

* Doing it for “HTTP APIs” — Same issues as above, maybe a bit more manageable because the APIs tend to be code-managed / database-backed more.

* Doing it for the incremental update case mentioned in the draft’s appendix — I find this really intriguing, but it’s obviously half-baked.

What do people think? Not asking if we should adopt it, just whether I should rev the draft.

Cheers,

Begin forwarded message:

> From: IETF Secretariat <[email-masked]>
> Subject: Expiration impending: <draft-nottingham-http-patch-status-00.txt>
> Date: 8 September 2014 1:42:05 pm GMT+2
> To: "Mark Nottingham" <[email-masked]>
> 
> The following draft will expire soon:
> 
> Name:     draft-nottingham-http-patch-status
> Title:    The 2NN Patch HTTP Status Code
> State:    I-D Exists
> Expires:  2014-09-14 (in 5 days, 19 hours)
> 

--
Mark Nottingham   http://www.mnot.net/

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Thu, 11 Sep 2014 14:16:08 +0000

--------
In message <[email-masked]>, Mark Nottingham wri

>What do people think? Not asking if we should adopt it, just whether I 

I see and recognize the potential bandwidth savings, but quite frankly
the very idea scares me from a consistency point of view.

At the very least, if we do this, some kind of integrity check (ie:
a MD5 checksum or similar) should be included in the scheme, so
that the client can check that the patch operation gave the right
result.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[email-masked]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

---

From: Julian Reschke <[email-masked]>
Date: Thu, 11 Sep 2014 16:24:18 +0200

On 2014-09-11 15:27, Mark Nottingham wrote:
> ...

I read it in preparation for the Toronto meeting, and liked the idea. 
The interesting question is whether anybody is planning to actually use it?

Best regards, Julian

---

From: Martin Thomson <[email-masked]>
Date: Thu, 11 Sep 2014 10:30:57 -0700

> that the client can check that the patch operation gave the right

Yes.  ETag doesn't cut it for this.

---

From: Julian Reschke <[email-masked]>
Date: Thu, 11 Sep 2014 21:45:29 +0200

> Yes.  ETag doesn't cut it for this.

I've been toying with the idea of defining a replacement for Content-MD5 
(clarity on 206, hash algorithm agility, maybe a conditional header 
field, potentially consistent with the SRI spec).

Best regards, Julian

---

From: Martin Thomson <[email-masked]>
Date: Thu, 11 Sep 2014 15:09:16 -0700

On 11 September 2014 12:45, Julian Reschke <[email-masked]> wrote:
> (clarity on 206, hash algorithm agility, maybe a conditional header field,
> potentially consistent with the SRI spec).

That sounds like it's worthwhile, if you can find a customer.

Bootstrapping off SRI seems pretty natural here.  You get an SRI link,
you make a request with an If-Content-Hash conditional and you avoid
downloading content that doesn't match, if your server is honest.  Not
a huge gain though, because it's not exactly recoverable if you don't
get a match and it still doesn't help for servers that don't support
the conditional (or malicious servers).

The more interesting uses are for patching scenarios where you might
want to be properly sure that the content you are patching is the
content you think.

---

From: "Martin Nilsson" <[email-masked]>
Date: Fri, 12 Sep 2014 07:32:48 +0200

> Yes.  ETag doesn't cut it for this.

Is that something we can fix? I've wanted to make a content based ETag  
using RFC 6920 named information URL segment, with some extra processing  
rules for the user agent, for a while. The reason I looked at this to  
begin with was to address ETag based tracking cookies and as a low  
friction protection against active attacks like packet injection to tack  
data at the end of payload. It doesn't quite solve that, but it provides  
better integrity checks on delivered content than the CRC of deflated data.

/Martin Nilsson

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/

---

From: "Buzonas, Steve" <[email-masked]>
Date: Fri, 12 Sep 2014 01:51:05 -0400

> On Sep 11, 2014, at 6:14 PM, "Martin Thomson" <[email-masked]> wrote:
>
Passing an MD5 sum won't really cut it either. Each hop could replace the value with whatever it decides to tack on.

Steve Buzonas
Web Developer
Carnegie Learning, Inc.
(888) 851-7094 x141 toll free
(412) 690-2444 fax
[email-masked]
www.carnegielearning.com

---

From: Martin Thomson <[email-masked]>
Date: Fri, 12 Sep 2014 07:28:31 -0700

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

---

From: James M Snell <[email-masked]>
Date: Fri, 12 Sep 2014 09:39:22 -0500

So long as the integrity check is optional, that would be fine... it
just won't work with some patch formats (e.g. JSON Merge Patch [1] ).

[1] http://tools.ietf.org/html/draft-ietf-appsawg-json-merge-patch-07

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Fri, 12 Sep 2014 14:41:40 +0000

--------
In message <CABkgnnWgA+cTwUcxF_kt1SQsmEz5X4=82G=[email-masked]>
>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 ?

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 15 Sep 2014 15:20:30 -0400

Ideally, the patch format would carry something to do that. If not, we’d 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 it’d be a bit ugly, I suspect, if it’s carried in headers).

Cheers,