Subject: Fwd: I-D Action:draft-snell-http-prefer-03.txt

From: Mark Nottingham <[email-masked]>
Date: Tue, 29 Mar 2011 11:17:56 +0200

FYI. 

Begin forwarded message:

> From: [email-masked]
> Date: 28 March 2011 10:30:01 PM GMT+02:00
> To: [email-masked]
> Subject: I-D Action:draft-snell-http-prefer-03.txt
> Reply-To: [email-masked]
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 	Title           : Prefer Header for HTTP
> 	Author(s)       : J. Snell
> 	Filename        : draft-snell-http-prefer-03.txt
> 	Pages           : 6
> 	Date            : 2011-03-28
> 
> This specification defines an HTTP header that can be used by a
> client to request that certain behaviors be implemented by a server
> while processing a request.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-snell-http-prefer-03.txt
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

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

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Tue, 29 Mar 2011 09:31:00 +0000

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

>> http://www.ietf.org/internet-drafts/draft-snell-http-prefer-03.txt

Couldt we please try to make it a habit to include some kind of use-case
or justification for these "bolt-on" drafts ?

It's probably my imagination that is flawed, but the only mental connection
I can attach to this draft is RFC748, so somebody please explain:

1. Whats the point.

2. How dows this help.

3. How much will it help.

Poul-Henning

-- 
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: Mark Nottingham <[email-masked]>
Date: Tue, 29 Mar 2011 11:33:39 +0200

Sitting here with Roy, who's asking much the same question. James, I know there was a discussion about this a while back, but it's new to many; can you give an overview?

Cheers,

---

From: "Roy T. Fielding" <[email-masked]>
Date: Tue, 29 Mar 2011 11:46:35 +0200

> 3. How much will it help.

heh, I just asked Mark the same question ...

The goal seems to be to ask for the server's result of a PUT or POST
to be returned as part of the same action instead of requiring the
client to make an additional GET request.

The problem with any such desire is that the mechanism handling
a PUT is not always in control of the resource's final state.  The
reason is simply that the mechanism for handling GET may be an
entirely different system from that handling PUT, may have access
to additional sources of metadata, and may be impacted by background
jobs independent of the HTTP request (i.e., event-based triggers on
content changes that result in workflows being run that eventually
change the content shortly after the client has received its response).
Moreover, the programmer writing the PUT handler is probably not
the same programmer developing those other systems, so this feature
is not going to be very reliable.

I agree, the draft should contain use cases to justify the feature
and make it clear that it may only work with very simple,
synchronous, self-contained implementations.

....Roy

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Tue, 29 Mar 2011 10:12:34 +0000

In message <[email-masked]>, "Roy T. Fielding" w

>client to make an additional GET request.

And standardizing a header to kindly request but not demand this,
would help how ?

Is the hope that all browsers will send this by default ?

Or is this intended only for obscure corner cases, were an private
X-FOO header or URI variable would be a better and more narrowly
tailored solution anyway ?

I'm sorry if this sounds cranky, but I don't believe that "as many
options as possible" is the right mental frame for writing standards,
Occams razor is much better:  If this is already possible through
existing means, why do we need it as a separate standard ?

Poul-Henning

---

From: Cyrus Daboo <[email-masked]>
Date: Tue, 29 Mar 2011 23:14:11 -0400

Hi Poul-Henning,

> Is the hope that all browsers will send this by default ?

Browsers are not the only HTTP clients around.

In the CalDAV (RFC4791) world we do have servers immediately modifying data 
PUT by clients with the requirement that clients then have to immediately 
do a GET. This happens because the server typically does take immediate 
action to do some form of scheduling - that may simply be to add an 
indicator to the data that a scheduling operation is pending (and that 
operation then happens asynchronously). Avoiding the extra roundtrip would 
be beneficial in this case particularly as mobile devices make use of this 
service.

That said, I agree with Roy that adding clarifying text about appropriate 
use cases makes sense.

-- 
Cyrus Daboo

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 30 Mar 2011 12:58:34 +0800

On 2011-03-30 at 05:14:11, Cyrus Daboo wrote:
> >> The goal seems to be to ask for the server's result of a PUT or 
> >> POST to be returned as part of the same action instead of requiring 
> >> the client to make an additional GET request.
> >
> In the CalDAV (RFC4791) world we do have servers immediately modifying 
> data PUT by clients with the requirement that clients then have to 
> immediately do a GET. This happens because the server typically does 
> take immediate action to do some form of scheduling - that may simply 
> be to add an indicator to the data that a scheduling operation is 
> pending (and that operation then happens asynchronously). Avoiding the 
> extra roundtrip would be beneficial in this case particularly as 
> mobile devices make use of this service.

Having a PUT and GET merged sounds like a useful idea.

There's an inherent assumption in this that I don't think you've considered.  The response to a PUT might already be an entity with some purpose (e.g. feedback about the change of a different nature).  For one, that means that - unlike a regular GET - the entity in the response cannot be assumed to be a representation of the resource.  That doesn't mean that you can't merge the two, but I'd have to suggest a specific indication.  It might be as simple as setting Content-Location.

--Martin

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Wed, 30 Mar 2011 06:51:03 +0000

>That said, I agree with Roy that adding clarifying text about appropriate 

Cool, so now I just wonder why we need to "spend" an RFC on a header
which is an optional polite query ?

Wouldn't it be smarter to RFC4791 and give the header more bite than
a polite request ?

---

From: Julian Reschke <[email-masked]>
Date: Wed, 30 Mar 2011 09:29:16 +0200

On 30.03.2011 06:58, Thomson, Martin wrote:
> ...
 > ...

<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-13.html#identifying.response.associated.with.representation>, 
item 3, indicates that Content-Location can be used for this.

Best regards, Julian