tip change of net/http semantics
297 views
Skip to first unread message
Gustavo Niemeyer
Jun 25, 2012, 2:43:40 PM6/25/12
to golang-dev, Brad Fitzpatrick
Hello all,
In go1*, one can return an error from a CheckRedirect implementation
and Do will return the last response, besides the error.
The following revision (surprisingly given its summary) changed that:
changeset: 13619:f7839a55036e
user: Brad Fitzpatrick <brad...@golang.org>
date: Tue Jun 19 09:10:14 2012 -0700
summary: net/http: clarify client return values in docs
After this change, the response is nil.
I can workaround the change, but besides the API breakage it feels
sane to have the last response in those situations, since the idea of
not redirecting is to avoid another request rather than poisoning the
previous response.
Looking at the change set, it seems that a similar behavioral change
was done for RoundTrip as well. I'm not being affected by this one,
but it's probably worth taking it into account as a behavior change
too, at least to properly document it as such.
gustavo @ http://niemeyer.net
In go1*, one can return an error from a CheckRedirect implementation
and Do will return the last response, besides the error.
The following revision (surprisingly given its summary) changed that:
changeset: 13619:f7839a55036e
user: Brad Fitzpatrick <brad...@golang.org>
date: Tue Jun 19 09:10:14 2012 -0700
summary: net/http: clarify client return values in docs
After this change, the response is nil.
I can workaround the change, but besides the API breakage it feels
sane to have the last response in those situations, since the idea of
not redirecting is to avoid another request rather than poisoning the
previous response.
Looking at the change set, it seems that a similar behavioral change
was done for RoundTrip as well. I'm not being affected by this one,
but it's probably worth taking it into account as a behavior change
too, at least to properly document it as such.
gustavo @ http://niemeyer.net
Russ Cox
Jun 25, 2012, 2:45:40 PM6/25/12
to Gustavo Niemeyer, golang-dev, Brad Fitzpatrick
Seems like we should document the old behavior instead of trying to fix it.
Russ
Russ
Brad Fitzpatrick
Jun 25, 2012, 2:59:14 PM6/25/12
to r...@golang.org, Gustavo Niemeyer, golang-dev
This was already discussed during the review. I flagged this as a change, but it was undocumented before and non-Go like, returning (non-nil, non-nil error), and I couldn't see how it would be useful.
Gustavo, apparently you found the old undocumented/untested behavior useful somehow? How?
minux
Jun 25, 2012, 3:25:28 PM6/25/12
to Brad Fitzpatrick, r...@golang.org, Gustavo Niemeyer, golang-dev
On Tue, Jun 26, 2012 at 2:59 AM, Brad Fitzpatrick <brad...@golang.org> wrote:
This was already discussed during the review. I flagged this as a change, but it was undocumented before and non-Go like, returning (non-nil, non-nil error), and I couldn't see how it would be useful.
io.Reader is allowed to return len(buf), non-nil error too, and I think that's also confusing.
(this is a different problem though)
Gustavo Niemeyer
Jun 25, 2012, 3:29:32 PM6/25/12
to Brad Fitzpatrick, r...@golang.org, golang-dev
On Mon, Jun 25, 2012 at 11:59 AM, Brad Fitzpatrick <brad...@golang.org> wrote:
> This was already discussed during the review. I flagged this as a change,
> but it was undocumented before and non-Go like, returning (non-nil, non-nil
> error), and I couldn't see how it would be useful.
While that's not typical, conceptually it sounds sane to give back
> This was already discussed during the review. I flagged this as a change,
> but it was undocumented before and non-Go like, returning (non-nil, non-nil
> error), and I couldn't see how it would be useful.
mid-state if that mid-state is relevant. That's the case of several
functions in the io package, and that seemed like the case of response
in the http package.
> Gustavo, apparently you found the old undocumented/untested behavior useful
> somehow? How?
actual response from the server. If this is not a good way to do that,
I suggest having one.
gustavo @ http://niemeyer.net
Gustavo Niemeyer
Jul 3, 2012, 11:53:27 AM7/3/12
to golang-dev
Gustavo Niemeyer
Oct 11, 2012, 12:39:29 PM10/11/12
to golang-dev
Sadly, this bug made into the 1.0.3 release, and applications that
trusted on the 1.0.2 behavior are now broken and there's no way to
workaround the bug since there's no other way to access the
non-redirecting response.
Is there any plan for 1.0.4?
trusted on the 1.0.2 behavior are now broken and there's no way to
workaround the bug since there's no other way to access the
non-redirecting response.
Is there any plan for 1.0.4?
Andrew Gerrand
Oct 11, 2012, 6:46:31 PM10/11/12
to Gustavo Niemeyer, golang-dev
On 12 October 2012 03:39, Gustavo Niemeyer <gus...@niemeyer.net> wrote:
> Sadly, this bug made into the 1.0.3 release, and applications that
> trusted on the 1.0.2 behavior are now broken and there's no way to
> workaround the bug since there's no other way to access the
> non-redirecting response.
>
> Is there any plan for 1.0.4?
We had hoped not.
> Sadly, this bug made into the 1.0.3 release, and applications that
> trusted on the 1.0.2 behavior are now broken and there's no way to
> workaround the bug since there's no other way to access the
> non-redirecting response.
>
> Is there any plan for 1.0.4?
How important is this?
Gustavo Niemeyer
Oct 11, 2012, 10:53:43 PM10/11/12
to Andrew Gerrand, golang-dev
Hi Andrew,
On Thu, Oct 11, 2012 at 7:46 PM, Andrew Gerrand <a...@golang.org> wrote:
> On 12 October 2012 03:39, Gustavo Niemeyer <gus...@niemeyer.net> wrote:
>> Sadly, this bug made into the 1.0.3 release, and applications that
>> trusted on the 1.0.2 behavior are now broken and there's no way to
>> workaround the bug since there's no other way to access the
>> non-redirecting response.
>>
>> Is there any plan for 1.0.4?
>
> We had hoped not.
>
> How important is this?
Without the behavior we have in 1.0.2 and in tip after the bug was
fixed, I believe there's no way to access any information from an HTTP
server response when it includes a redirect code. This is useful in
many cases. A trivial example would be sniffing an authentication
cookie, which is commonly part of a redirect.
gustavo @ http://niemeyer.net
On Thu, Oct 11, 2012 at 7:46 PM, Andrew Gerrand <a...@golang.org> wrote:
> On 12 October 2012 03:39, Gustavo Niemeyer <gus...@niemeyer.net> wrote:
>> Sadly, this bug made into the 1.0.3 release, and applications that
>> trusted on the 1.0.2 behavior are now broken and there's no way to
>> workaround the bug since there's no other way to access the
>> non-redirecting response.
>>
>> Is there any plan for 1.0.4?
>
> We had hoped not.
>
> How important is this?
fixed, I believe there's no way to access any information from an HTTP
server response when it includes a redirect code. This is useful in
many cases. A trivial example would be sniffing an authentication
cookie, which is commonly part of a redirect.
gustavo @ http://niemeyer.net
Andrew Gerrand
Oct 14, 2012, 9:06:11 PM10/14/12
to Gustavo Niemeyer, golang-dev
In your opinion, does it warrant a go1.0.4?
Andrew
Brad Fitzpatrick
Oct 14, 2012, 9:08:51 PM10/14/12
to Andrew Gerrand, Gustavo Niemeyer, golang-dev
I think I can propose a workaround. Let me try tomorrow.
Gustavo Niemeyer
Oct 14, 2012, 10:10:35 PM10/14/12
to Andrew Gerrand, golang-dev
depending on such server responses can be unbroken. As a last resort,
I'll probably just copy over the whole http package from 1.0.2 or tip
whenever I need those responses, which isn't great.
gustavo @ http://niemeyer.net
Reply all
Reply to author
Forward
0 new messages