net/http.Request.ParseForm: support for PATCH

[robfig]

Hello,

My understanding is that PATCH requests are expected to have body content -- for example, the RFC[1] seems to say that PATCH and PUT requests are identical in structure and only differ in the server's interpretation of the provided content. 

Should ParseForm be patched to support PATCH requests?  Right now it only executes parsePostForm for POST and PUTs[2]. 

Thanks,

Rob

[1] http://tools.ietf.org/html/rfc5789

[2] http://golang.org/src/pkg/net/http/request.go?s=20322:20357#L701

[David Symonds]

Does a PATCH body qualify as a "form" in this sense? The examples in
RFC 5789 don't look like they'd be parseable by parsePostForm.

[Rob Figueiredo]

I don't have any practical experience with PATCH, but I don't think the RFC says anything about the format of the data -- just that it can be any document type.  I read it as being the same situation as POST, where the body may be form encoded (in which case ParseForm is helpful) or it may not be (e.g. when posting application/json). 

My understanding is that any of the HTTP verbs that are allowed to have bodies (POST, PUT, PATCH) can have a content type of application/x-www-form-urlencoded, in which case ParseForm should be useful.  (e.g. for ParseForm, it matters what the ContentType is, not the verb) 

[David Symonds]

ParseForm is a convenience function because it's very common for an
HTML <form> to use method=POST (or, to a lesser degree, method=PUT)
and get a particular encoding. I don't think PATCH falls into that
category as a "common" thing.

I'm not opposed to ParseForm accepting PATCH, but I just don't know if
it actually happens in practice.

[Rob Figueiredo]

Ah, I hadn't seen PUT on a HTML form before actually.  My impression was that PUT / PATCH are mostly used for REST APIs, where it's still common to have form encoding be a supported content type.  (Of course JSON is much more prevalent now..)

[Brenden]

I think the real issue is the http package's support for Put and Patch in general. If there are convenience methods for Get and Post, there should be convenience methods for Put and Patch.

At that point we could add support for Put and Patch form encoding, too. Like robfig said, Put and Patch are not very common in HTML form methods. I've actually never seen anything other than Post used. That said, according to the HTTP spec, it is possible, so we should support it since the http package is supposed to implement the HTTP spec.

[David Symonds]

On 17 November 2013 10:19, Brenden <bso...@gmail.com> wrote:

> I think the real issue is the http package's support for Put and Patch in
> general. If there are convenience methods for Get and Post, there should be
> convenience methods for Put and Patch.

We've discussed this quite a lot of times before; check the archives
for more details, but the general gist is that GET, HEAD and POST
cover something like 99% of HTTP requests, so having convenience
functions for them pays off. Adding more convenience methods just
clutters the net/http API for relatively little gain (and it's not
hard to use Do to use arbitrary HTTP verbs), and it's not clear where
one would draw the line. Put and Patch, but what about Delete?
Connect? SpaceJump?

Adding support for encoding types is more plausible, and you could
file something on the issue tracker if there are specific form
encodings that you think should be supported.

[Brenden]

I can see your point, but it just seems like being partial toward what is popular is not best practice. Adding one or two more convenience methods would add more value than it would take away.

Also, Delete is a real HTTP method as defined by the RFC, I don't recall connect or space jump. Just sayin'

[Jesse McNelis]

On Tue, Nov 19, 2013 at 4:24 PM, Brenden <bso...@gmail.com> wrote:

I can see your point, but it just seems like being partial toward what is popular is not best practice. Adding one or two more convenience methods would add more value than it would take away.

Also, Delete is a real HTTP method as defined by the RFC, I don't recall connect or space jump. Just sayin'

If we just had the ones from the RFC, then we'd need:

OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, CONNECT, PATCH, LINK, UNLINK

--
=====================
http://jessta.id.au

[David Symonds]

On 19 November 2013 16:24, Brenden <bso...@gmail.com> wrote:

> I can see your point, but it just seems like being partial toward what is
> popular is not best practice. Adding one or two more convenience methods
> would add more value than it would take away.

We can always add more convenience methods if they prove useful; the
backward compatibility guarantee does not permit us to take them away.
It's fine to wait for PUT and PATCH to get more popular; they'll work
in the meantime.

> Also, Delete is a real HTTP method as defined by the RFC, I don't recall
> connect or space jump. Just sayin'

http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.9
http://www.w3.org/Protocols/HTTP/Methods/SpaceJump.html

[Rodrigo Kochenburger]

I don't think there is any valid reason to not support PATCH (or any other verb).

The argument of GET/POST covering the majority of the cases is not so true anymore, since verbs are widely used for REST APIs, which Go is really good for.

My idea of how it should work is: ParseForm should verify content-type and read the body. If the verb does not support a body then trying to read it should fail, which ParseForm could happily return the error back to the user. Having ParseForm depend on the VERB directly is IMHO a really weird dependency to have.

Cheers

- RK

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.