[Bug 10671] consider removing support for PUT and DELETE as form methods

http://www.w3.org/Bugs/Public/show_bug.cgi?id=10671

--- Comment #8 from Mike Amundsen <mamund@yahoo.com> 2010-10-07 14:49:07 UTC ---
FWIW, I sense a bit of context-switching here in the reasons for dropping this
feature:

- "implementation in FF4 had two bugs" (Understood)
- "There's nothing wrong ... in principle" (I don't share that opinion<g>)
- "what's needed is a story about how PUT and DELETE is going to be used in
practice." (Provided)
- "...servers send 200/201/204 with a minimal status message when things go
right. How are these supposed to be used from an HTML form?" (The same as when
they returned by POST)
- "...whether servers that already support PUT and DELETE need to be
modified..." (I don't see why this is an issue and would like to see a worked
out case where this is a potential problem).

It seems the bug list is not the place for discussion on these items and I
don't have standing in W3C to post to html-public in order to pursue this. If
you care  to pursue it you can contact me in IRC or directly via email (mamund
-AT- yahoo -DOT- com).

Thanks for your time.
MCA

(In reply to comment #7)
> (In reply to comment #6)
> > I posted here based on a suggestion to "explain in detail..." my example of a
> > use case for PUT (http://krijnhoetmer.nl/irc-logs/whatwg/20101006#l-662).
> 
> Ack. And just for reference; I opened this bug because the
> (now-disabled/removed) implementation in FF4 had two bugs, one of which was
> about a bad target URI being computed, the other one with respect to handling
> redirects.
> 
> The former was a bug with respect to what HTML5 said, the latter isn't
> specified in HTML5, so the code just reused XMLHttpRequest behavior (which I
> think is broken as well). This made me nervous about this ever getting be done
> *right*.
> 
> > > The tricky question is how to actually *use* PUT and DELETE with HTML forms.
> > 
> > I think the uses of PUT/DELETE in the four frameworks I cited is clear,
> > correct?
> 
> As far as I can tell, these use POST to tunnel PUT/DELETE. There's nothing
> wrong about that in principle.
> 
> Maybe the disagreement is based on where we come from? I'm using servers that
> do support PUT and DELETE all the time. These servers send 200/201/204 with a
> minimal status message when things go right. How are these supposed to be used
> from an HTML form? Maybe they aren't supposed to?
> 
> > > The bug was raised because I think the spec (as it was back then) wasn't
> > > specific enough to make this work, and thus early adoption (such as in FF4)
> > > would make it very hard to do the right thing later on.
> > 
> > I understood that it was removed "until there's a clearer understanding
> > about what it's good for." Have I misinterpreted your remark in the bug
> > description?
> 
> I don't think so.
> 
> I think what's needed is a story about how PUT and DELETE is going to be used
> in practice. In particular, whether servers that already support PUT and DELETE
> need to be modified so this can be used from HTML forms; sending the request is
> simple, but what's less clear is what response codes are supported and how they
> affect the web application.
> 
> > I am familiar w/ this material. It's not clear to me (from your comment here)
> > how the content in Part 6 affects my remarks on POST's cacheability per HTTP
> > 1.1 vs. PUT and DELETE. More to the point, I see no changes in Part 2 
> > (http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-11.html) that
> > indicate a change in the cacheability of POST, PUT or DELETE. Can you help me
> > make sure I understand your point here?
> 
> Work in progress...
> 
> There shouldn't be special cases except for GET/HEAD. See
> <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/139> (we may have to re-open
> this issue, please follow up on the HTTP WG mailing list if you think more
> needs to be done).

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Thursday, 7 October 2010 14:49:09 UTC