Re: [gnome-network]Transfer Manager (again!)

[Rodney Dawes <dobey free fr>]

On Mar , 2003-10-21 at 16:12, Manuel Clos wrote:
> Rodney Dawes wrote:
> > No. Well, yes and no. It is detected and not handled could be said for
> > all headers and HTTP status codes that there is not specific code in the
> > module for already. However, that is not really the case. There are 3
> > common ways to do redirection. Firstly there are the 30x status codes. I
> > believe there are defines for these values, so that they have pretty
> > macro names, but nothing is done with them. Then there is the Location:
> > HTTP header. I tried to patch gnome-vfs to handle this method already,
> > and ended up being stuck between a rock and a recursively hard place. It
> > needs sufficient rewriting to be able to function correctly. There is
> > not enough information internal to handle this. However, there is a
> > callback that is passed all of the extra headers in a list, and support
> 
> Well you basically get 30x and Location: at the same time.

No. The code for handling headers is completely separate from when you
get an error code. Also, when you get a 30x error, "Location" is not
typically sent along with it.

> Did you 
> attached any patch comments to a bug at bugzilla? Where do you got stuck 
> and what the problems were?

I got "stuck" because it is not possible to change the URI on a
connection, inside of the header callback functions internal to the
HTTP module.

> > for Location: can be added to specific clients. Then there is the HTML
> > meta tag for doing a refresh, with a timeout. This requires parsing the
> > <head/> tag of the HTML document, and doing the necessary timeout stuff,
> > if one is set. So, this can be done in the client as well.
> 
> Well, I think we can go with the first case, then try to implement this 
> one. But I'm not sure we should handle it. I will ask teuf about it.

Yes. However, as I said, I don't think it can be done in the current
HTTP module code with the way it works. It is certainly doable in the
client though.

> >>Anyway teuf helps a lot. So it is doable.
> > I didn't say it wasn't doable. I said it wasn't doable in the current
> > code. It will require sufficient rewriting of the HTTP module.
> 
> Umh, I would like to see comments about this, where the problem is and 
> what needs changed. If you really think the solution is going with 
> libcurl, post a comment to the gnome-vfs list.

Simply using another library won't solve the problems. There will still
be other issues to deal with.

> >>Have you proposed the switch to libcurl in the gnome-vfs list? this will 
> >>be good since if the switch is going to happen, it makes no sense to fix 
> >>current gnome-vfs code.
> > I have not proposed this to the gnome-vfs list, no. But, I recall seeing
> > someone else having proposed the same thing. I don't remember where
> > though.
> 
> I talked with teuf. The good thing is that libcurl handles all the 
> stuff, the problem is that there are thread issues.

Why are there thread issues? It seems like there would be less threading
issues with libcurl. I don't know for sure, of course, but it certainly
seems like it.

-- dobey