Hacker News Reader

Comment by yxhuvud | Hacker News Reader

If anything, I'd rather have a HTML spec that allows forms to do the other resource oriented verbs.

Yes! Why is support for PUT and DELETE not specified in HTML specs? Also, why hasn't a browser implementation gone ahead and added support for both of those verbs as an extension beyond the spec?

> Yes! Why is support for PUT and DELETE not specified in HTML specs?

IIRC, it was in an earlier draft of the WHATWG HTML spec, was implemented in a beta version of Firefox, issues were raised with the semantics of the Firefox implementation that ended up becoming issues with the clarity of what browsers were supposed to do with PUT/DELETE forms in the draft HTML spec, and the result was taking PUT/DELETE support out of the spec because of the lack of agreement on what should be specified regarding the use of those methods with forms.

ISTR that this issue has been reopened as a bug with the spec since that time, though I don't know if it is currently open or not.

My understanding is that "PUT" means "make it so that the contents of this request body live at this URL". Meanwhile classic HTML forms only send lists of name/value pairs. So it would have been saying "make it so that this list of name/value pairs lives at this URL" which isn't very useful and would likely have led to widespread creative abuse and corruption of the meaning of "PUT".

Likewise, it doesn't make much sense to send a request body with a DELETE, regardless of what it contains. Not forbidden, but not really useful either.

The server can do whatever processing it likes to a PUT's request body. If you upload a PNG it can convert it to a JPEG or an SVG or OCR it or invert the colors, etc. It's perfectly valid to turn application/x-www-form-urlencoded into something else.

Converting "image/png" to "image/jpeg" is easy given a knowledge of those formats, but how do you convert "application/x-www-form-urlencoded" to "image/jpeg" or "text/html" or anything else? The only thing you can do is invent your own arbitrary convention, which begins to stray pretty far from the design and intent of PUT.

That would depend on what kind of service you're implementing.

"HTTP/1.1 does not define how a PUT method affects the state of an origin server."

I don't think it was ever the design or intent of PUT to store the exact representation that you gave it, and I would be surprised to see evidence otherwise.

Conceptually it's no different from POSTing (or PUTting) application/json to produce a resource that will be represented as text/html. How do you convert JSON to HTML? Depends on the service.

The only real difference between PUT and POST is that PUT creates a resource at a defined location. There's no difference with regard to the mapping-from-request-representation-to-preferred-server-representation between PUT and the common use case of POST to create a new member of a collection where the collection URI is the target of the POST, the only difference is that with put, the target URI is the location that the resulting resource will be placed rather than the location it will be subordinate to.

Since this problem isn't a barrier to using POST to create resources, it shouldn't be for PUT, either.

HTTP and HTML are two different things. If you don't like HTML you are welcome to use a different markup format.

This post is all about how the author thinks the other verbs are useless, and they are pretty much useless in the browser. However, HTTP is not just for browsers...

But it seems to me that one of HTTP's prime benefits is its ubiquity. And it's ubiquity is due entirely to its use by browsers.

Reply on news.ycombinator.com