I'll take a poke at it tonight - right now the sun's up and I'm supposed to be
asleep :)

I guess if the url starts with ./ it'll be ok to hack it off, or even wait until
just before sending out the url and then run along it taking out any ./ that
crept in?

But I'm afraid that it should probably be more generic than that, right? In the
case of the ../ that Kevin mentioned, the next-to-the-left directory name (if
there is one) should be removed, then the whole process repeated until either no
directory name fall between the server and the ../, or until there are no more
../s. Did that make sense?

I don't suppose there's a 'canonicalise path' function in the C library, is
there? That would be just too easy... :) Even as I type I'm looking this up -
and yes, there is... It's called 'realpath'. Unfortunately it also "expands all
symbolic links", so it probably relies on the file existing in the filesystem
somewhere. Still, I suppose a slightly modified version would work just fine...

I still think the server is somewhat busted - MS IIS5.0 - I tried the
dir/./dir/file thing on an Apache server and it didn't even blink. Gave me the
correct file immediately. Of course I'm insanely biased against IIS, but even
so... :)

Ralph

Daniel Stenberg wrote:

> On Thu, 3 Oct 2002 rmitchell_at_eds.com wrote:
>
> > OK, first off, this may not be a curl issue, and I'm happy if someone can
> > give me chapter and verse telling me why not.
>
> Unfortunately, I very much think this is a curl issue.
>
> > What I'm seeing is this: I go to fetch a page from server X, get a bunch
> > of redirects that end up at server Y, which presents a login page. I post
> > back the relevant fields to server Y, which then sends more redirects, the
> > last of which looks like this:
> >
> > Location: ./welcome.jsp
> >
> > along with a cookie or two. curl inserts the path to the file and tries to
> > fetch:
> >
> > http://serverY/dirA/dirB/./welcome.jsp
> >
> > which gets me "500: Server Error [00-0002]".
>
> Right. Curl has no knowledge about the "./" concept. This is certainly a flaw
> we need to fix.
>
> I'll dig into this as soon as possible. Hopefully I can produce a patch for
> this until tomorrow or so.
>
> > I might be able to beat up the owners of serverY and get them to take out
> > the ./, because that's essentially a no-op, but I suspect it may be 3rd
> > party code and therefore a lot harder to get corrected.
>
> That might be a work-around for now, yes, but I think curl should be able to
> deal with this simple and fairly common case.
>
> lib/transfer.c:1365 could be a place to start looking at.
>
> --
> Daniel Stenberg -- curl related mails on curl related mailing lists please
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf

-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
Received on 2002-10-03