FAQ
Hi,


Currently when using http.Post, if the client receives a 302 it
automatically
issues a GET to the new location. However for a 301 no attempt is made to
follow the redirect.

Is there a rationale for this?

I noticed the python HTTP client, and browsers, will follow both 301s and
302s
from POST requests (although technically the HTTP spec disallows this
behaviour)

thanks
pranav

--
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/d/optout.

Search Discussions

  • Egon at Apr 14, 2014 at 6:17 am
    http://tools.ietf.org/html/rfc2616#section-10.3.2

    If the 301 status code is received in response to a request other

    than GET or HEAD, the user agent MUST NOT automatically redirect the

    request unless it can be confirmed by the user, since this might

    change the conditions under which the request was issued.


    So yeah, probably because the spec says that user agent MUST NOT
    automatically redirect. So the Python HTTP client/browser are not following
    the spec properly.

    + egon
    On Monday, April 14, 2014 9:11:47 AM UTC+3, Pranav Raja wrote:

    Hi,


    Currently when using http.Post, if the client receives a 302 it
    automatically
    issues a GET to the new location. However for a 301 no attempt is made to
    follow the redirect.

    Is there a rationale for this?

    I noticed the python HTTP client, and browsers, will follow both 301s and
    302s
    from POST requests (although technically the HTTP spec disallows this
    behaviour)

    thanks
    pranav
    --
    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/d/optout.
  • Pranav Raja at Apr 14, 2014 at 6:38 am
    Yup, that definitely makes sense. However if we're following the HTTP spec,
    then technically only 303s can be reissued as GET requests.

    So the Go HTTP client is treating 302s like 303s.

    Compare Ruby's net/http, which (correctly) doesn't follow 301s or 302s.

    I know the behaviour can't be changed but I was just curious whether it was
    a
    conscious choice.

    --
    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/d/optout.
  • Egon at Apr 14, 2014 at 6:48 am

    On Monday, April 14, 2014 9:38:05 AM UTC+3, Pranav Raja wrote:

    Yup, that definitely makes sense. However if we're following the HTTP spec,
    then technically only 303s can be reissued as GET requests.

    So the Go HTTP client is treating 302s like 303s.

    Compare Ruby's net/http, which (correctly) doesn't follow 301s or 302s.

    I know the behaviour can't be changed but I was just curious whether it
    was a
    conscious choice.
    It would be a difficult call, if you think it can't be changed due to the
    Go1 compatibility guarantee, then it doesn't apply to bugs. In other words
    if something doesn't implement a spec correctly then the initial code is
    buggy.

    Of course it's not as simple as let's just follow the spec because a lot of
    servers do not distinguish between 302 and 303.

    This (probably) warrants an issue report.

    + egon

    --
    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/d/optout.
  • Will Norris at Apr 14, 2014 at 3:57 pm
    the more relevant section is
    http://tools.ietf.org/html/rfc2616.html#section-10.3.3

        If the 302 status code is received in response to a request other
        than GET or HEAD, the user agent MUST NOT automatically redirect the
        request unless it can be confirmed by the user, since this might
        change the conditions under which the request was issued.

           Note: RFC 1945 and RFC 2068 specify that the client is not allowed
           to change the method on the redirected request. However, most
           existing user agent implementations treat 302 as if it were a 303
           response, performing a GET on the Location field-value regardless
           of the original request method. The status codes 303 and 307 have
           been added for servers that wish to make unambiguously clear which
           kind of reaction is expected of the client.

    It's confusing that the spec clearly says clients MUST NOT following 302
    redirects for POST, but the note says that many implementations do anyway.
      Unfortunately, the relevant issue and change doesn't have too much
    discussion on the decision to follow 302's, though I suspect it was a
    simply pragmatic decision, given that so many applications continue to use
    302 rather than 303. Brad?

    https://code.google.com/p/go/issues/detail?id=4145
    https://codereview.appspot.com/6923055



    On Sun, Apr 13, 2014 at 11:48 PM, egon wrote:
    On Monday, April 14, 2014 9:38:05 AM UTC+3, Pranav Raja wrote:


    Yup, that definitely makes sense. However if we're following the HTTP
    spec,
    then technically only 303s can be reissued as GET requests.

    So the Go HTTP client is treating 302s like 303s.

    Compare Ruby's net/http, which (correctly) doesn't follow 301s or 302s.

    I know the behaviour can't be changed but I was just curious whether it
    was a
    conscious choice.
    It would be a difficult call, if you think it can't be changed due to the
    Go1 compatibility guarantee, then it doesn't apply to bugs. In other words
    if something doesn't implement a spec correctly then the initial code is
    buggy.

    Of course it's not as simple as let's just follow the spec because a lot
    of servers do not distinguish between 302 and 303.

    This (probably) warrants an issue report.

    + egon

    --
    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/d/optout.
    --
    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/d/optout.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedApr 14, '14 at 6:11a
activeApr 14, '14 at 3:57p
posts5
users3
websitegolang.org

3 users in discussion

Pranav Raja: 2 posts Egon: 2 posts Will Norris: 1 post

People

Translate

site design / logo © 2021 Grokbase