Grokbase › Groups › Go › golang-nuts › August 2013
FAQ
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

--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

  • David Symonds at Aug 5, 2013 at 1:40 am ⇧
    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.

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Rob Figueiredo at Aug 5, 2013 at 1:53 am ⇧
    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)

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • David Symonds at Aug 5, 2013 at 1:58 am ⇧
    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.

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Rob Figueiredo at Aug 5, 2013 at 2:05 am ⇧
    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..)

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Brenden at Nov 17, 2013 at 1:39 am ⇧
    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.
    On Sunday, August 4, 2013 6:32:47 PM UTC-7, robfig wrote:

    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
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • David Symonds at Nov 17, 2013 at 2:31 am ⇧

    On 17 November 2013 10:19, Brenden 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.

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Brenden at Nov 19, 2013 at 5:26 am ⇧
    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'
    On Saturday, November 16, 2013 6:31:27 PM UTC-8, David Symonds wrote:

    On 17 November 2013 10:19, Brenden <bso...@gmail.com <javascript:>>
    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.
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Jesse McNelis at Nov 19, 2013 at 5:50 am ⇧
    On Tue, Nov 19, 2013 at 4:24 PM, Brenden 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

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • David Symonds at Nov 19, 2013 at 5:56 am ⇧

    On 19 November 2013 16:24, Brenden 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

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Rodrigo Kochenburger at Nov 19, 2013 at 3:26 pm ⇧
    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

    On Tue, Nov 19, 2013 at 3:56 AM, David Symonds wrote:
    On 19 November 2013 16:24, Brenden 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

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedAug 5, '13 at 1:32a
activeNov 19, '13 at 3:26p
posts11
users5
websitegolang.org

5 users in discussion

David Symonds: 4 posts Rob Figueiredo: 3 posts Brenden: 2 posts Rodrigo Kochenburger: 1 post Jesse McNelis: 1 post

Content

People

Support

Translate

site design / logo © 2022 Grokbase