On Fri, 12 Oct 2001, T. Bharath wrote:

> >4. We follow that and get the above URL as well, which returns a BAD
> >redirect:
> >Location: http://LS.asp?DGC=DC
>
> This is the problem.Actually this <http://LS.asp?DGC=DC> is not a
> redirect.

I'm sorry, I don't follow you here. Could you please elaborate? I'll show you
my approach:

If I use the URL I wrote down in my previous reply, I get a header returned
from the server that looks like one above. That _is_ a bad redirect, or I am
halucinating. I can't get it to make the mistake you posted about.

I can't get curl to misunderstand a '//' occurrence in the Location:
header.

> The Curl Parser searches for the protocol string in step 3
> LS.asp?DGC=DC&DGU=%25m&DGSite=MSN&DGStor=DHS&RURL=Dell4Me&DURL=http%3A//
> dell4me.com?DGVCode=DC&mc=%25m&Visits=1

> Since the search is basically an strstr for // it returns the position of
> http%3A//dell4me.com(since the url is relative) as part of the payload
> and it mistakenly assumes it to be the url and starts trying with that.

I can't see this happening when trying, and I can't see this in the code.

There's a slight possibilty for an error, but that's not because of a
strstr() but because of the sscanf("15[^:]://") since that doesn't really
check that there's a valid proto string, only that there's a maximum of 15
letters and then a :// sequence. (I'll correct this with a better pattern
than [^:]).

The strstr() for // that you're referring to (transfer.c:1008 in my copy)
scans for the end of the protocol part in the *already* used URL (as opposed
to the string received in the Location: header). Since 7.9, we never deal
with URLs internally without them being prefixed with a protocol part (it'll
get prepended if one is passed to libcurl without one), so I can't see how
the strstr() could possibly find the wrong //-string there.

-- 
    Daniel Stenberg -- curl groks URLs -- http://curl.haxx.se/