User talk:Stilkov/ISSUE-195

Support for headers

My take: Don't do it know, stick to the simpler variant to get something at all. --Stefan Tilkov 19:20, 7 June 2012 (UTC)

Isn't @enc-type a pre-existing example of something that dictates the construction of the HTTP request, including a header (Content-Type)? --Jon Moore 19:26, 7 June 2012 (UTC)

Very much so, yes. Again, I don't disagree at all that adding additional header support, or declarative support for constructing HTTP requests in general, is an excellent idea. My feeling is that such a proposal would be too hard to get right quickly, though, and would inevitably be postponed. Getting at least some support for PUT and DELETE would be better than nothing. Can I please ask you to bear with me here for a few iterations? --Stefan Tilkov 19:49, 7 June 2012 (UTC)

Sure, I'm willing to defer to folks with more experience in the standards process. --Jon Moore 19:58, 7 June 2012 (UTC)

Then that would need to be Mike, I guess :-) I have experience with the JCP, not with the W3C. But I'm sure you've seen the reaction to this one, right? http://www.w3.org/wiki/User:Cjones/ISSUE-195 --Stefan Tilkov 20:02, 7 June 2012 (UTC)

I hadn't seen the reaction, but I can guess at what it was. That proposal is really hard to read/understand. --Jon Moore 20:20, 7 June 2012 (UTC)

I suspect the Atom-Style proposal is so limited in funcitonaltiy that it will not meet most people's needs for PUT/DELETE. But I'm OK w/ starting there and seeing what happens as we go along. --Mike Amundsen 19:33, 7 June 2012 (UTC)

Actually, I think pulling the Etag from the hosted page could work even with multiple forms; it just requires the server to be a little more clever about what Etags it provides. --Jon Moore 19:58, 7 June 2012 (UTC)

I've been thinking about this some more, and now I'm back to wanting to embed validators in the form itself, because while conditional GETs are optimizations, conditional PUTs and DELETEs are important semantics for optimistic locking. In particular, if a client has never retrieved a resource, there is no way for it to issue a conditional PUT or DELETE to it. In addition, the most relevant ETag for a form submission is likely not the ETag from a previous retrieval but rather the appropriate ETag at the time of form generation (consider that the way to accomplish conditional updates currently is to use a POST and include a hidden input with the appropriate ETag in it). --Jon Moore 11:37, 10 June 2012 (UTC)

This actually makes me wonder: What's the appropriate server action if it expects a conditional PUT, but gets an unconditional one? --Stefan Tilkov 19:27, 10 June 2012 (UTC)

Also, I'm still not fully convinced we should open this can of worms. Consider: What's the appropriate format for this header? In the way Mike describes it in his proposal? Or maybe there should be form fields of type "input"? --Stefan Tilkov 19:27, 10 June 2012 (UTC)

Did you mean an input of type "header"? Because I was just thinking of that myself. Browsers could largely treat them as hidden inputs (not showing them) but then processing them on form submission.--Jon Moore 20:33, 10 June 2012 (UTC)

Handling DELETE

As a wild idea, I was wondering whether DELETE shouldn't be handled more like GET in terms of URI construction. It seems it would be useful to e.g. allow someone to use a select element to construct a URI the DELETE is sent to. But maybe that's an entirely stupid idea. What do you think? --Stefan Tilkov 19:49, 7 June 2012 (UTC)

Actually, I think passing <input> values as query parameters seems pretty natural (like method=GET). --Jon Moore 19:58, 7 June 2012 (UTC)

My concern is that people would start wondering why we don't this for PUT too, then (which we can't, as the form values are meant to build the entity body).--Stefan Tilkov 20:00, 7 June 2012 (UTC)

Although that's not a problem w/ GET vs. POST currently. --Jon Moore 02:34, 8 June 2012 (UTC)

I've updated the appropriate places to reflect handling DELETE and GET similarly for now. --Stefan Tilkov 08:07, 8 June 2012 (UTC)

Positive Effects

Actually, the main benefits are from proxies in general, which can retry PUTs and DELETEs. From a caching point of view otherwise, PUTs and DELETEs aren't any different than POSTs. So I suggest just removing the word "caching" and just having "proxies". --Jon Moore 02:37, 8 June 2012 (UTC)

Good point, I've changed it in the rationale, too. --Stefan Tilkov 06:23, 8 June 2012 (UTC)

Handling non-HTTP @actions

How to handle other protocols (FTP, mail) and data URIs? --Stefan Tilkov 08:05, 8 June 2012 (UTC)

PUT and DELETE have corresponding actions for FTP (actually, much clearer ones than for POST!), so that seems pretty natural. How does the spec currently handle POSTs to non-http URIs? Does the spec even allow non-URLs in @action? --Jon Moore 10:27, 8 June 2012 (UTC)

Yes, it allows them -- see the table I copied from the spec (and the appropriate section there). --Stefan Tilkov 19:24, 10 June 2012 (UTC)

History Navigation

What is the correct behavior for handling history navigation with PUT and DELETE requests? Is it OK to simply re-issue them (as they are idempotent) or should the user be asked for confirmation (because they're not safe)? --Stefan Tilkov 08:05, 8 June 2012 (UTC)

Note that history navigation does NOT reissue requests except when crossing a redirect ("you broke the back button!"). If the result of a POST is a 200 OK with HTML in the body, for example, browsers can navigate forward and back across that without reissuing anything. For the redirect-crossing case, I can see arguments both ways for PUTs and DELETEs. We can break the tie here with the Principle of Least Surprise: for a long/old browser history, I would probably be surprised if a browser re-issued a non-safe request without confirmation.--Jon Moore 10:54, 8 June 2012 (UTC)

Open issues

• After discussing the possibility of a "header" input, I'm going to flip all the way back to maybe not discussing ETags at all, and just focusing on getting PUT and DELETE added as @method values. I'm now fully convinced that the header issue is a different issue; I think we should leave ETags out of this proposal entirely as a result.--Jon Moore 11:14, 11 June 2012 (UTC)

I can see the reasoning, let me think about this for some time. --Stefan Tilkov 18:47, 12 June 2012 (UTC)

• I started stubbing out a proposal for simple header handling: [1]