cURL / Mailing Lists / curl-library / Single Mail


Re: libcurl stumbles on weird redirect location

From: Alex Vinnik <>
Date: Tue, 27 Dec 2011 16:58:42 -0600

Well... it is clearly something is wrong with the site. I noticed one
interesting thing with Chrome you can reproduce it by following these steps
1. Open chrome://net-internals/#events it will start chrome logging
2. clean chrome cache and cookies
3. paste**promo/**qpF0HYnRugA-**
address bar
4. hit Enter

Chrome removes url from address bar and doesn't display anything in view
area. Check chrome://net-internals/#events you will see that site responded
with ill-formed Location header. Seems like Chrome fails (--> net_error =
-3 (ABORTED)) and ignores but in fact it caches a cookie received with
redirect response which is used later. Now paste the url again and hit
enter you will see well-formed Location header in
chrome://net-internals/#events and browser handles it well. Because cookie
comes from cache now and sent to the server with first request. But that is
not all... when I provide dummy cookie with seed url request than I get
correct Location. So I settled with ugly workaround like this for now.
However it looks like Chrome has some room for an improvement as well. Do
you know how submit a bug report to them?

On Tue, Dec 27, 2011 at 12:07 PM, Daniel Stenberg <> wrote:

> On Sun, 25 Dec 2011, Alex Vinnik wrote:
> You are right about that;****jsessionid=**
>> 0000EXsMRFMF5kwJo26qgOif31d:****13ddq0tfm is treated as search term by
>> Chrome BUT I am afraid I was not entirely clear that THIS url
>> 63LcCNNtsuVrjXbS8XCqNA&url=**<>needs to be used as seed one. The server responds with 301 with that weird
>> "Location" header. However when you try this seed url in chrome it
>> navigates correctly to new location. The mystery for me is that Chrome
>> seems to get well-formed location header in contrast to curl. Here is
>> Chrome log captured from chrome://net-internals/#**events. Please see
>> below...
> That's not really strange. The site probably has some nasty and broken
> heuristics to figure out what browser that is in use and then it sends back
> different responses - including headers.
> The Firefox version of the URLs are still wrong.
> By the way, my Firefox bug report for this issue is now here:
>**show_bug.cgi?id=713472<>and it seems that Firefox 9 will not treat those URLs as legal ones and
> then that site might have to do something else...
> Any special requests headers that make the difference? Wonder if I can
>> achieve similar effect with curl.
> If you compare both Firefox's and Chrome's "route" you might detect
> differences. They may also very well use javascript or whatever to detect
> what's in use and act from that.
> --
> /
> ------------------------------**------------------------------**-------
> List admin:**listinfo/curl-library<>
> Etiquette:**etiquette.html<>

List admin:
Received on 2011-12-28