On Jul 9, 2007, at 22:00, Brent Fulgham wrote:
On Jul 9, 2007, at 8:26 AM, Ryan Schmidt wrote:
On Jul 9, 2007, at 09:45, Doug McCorkle wrote:
The correct fetch.ignore_sslcert command solved my problems. In
regards to the args command I thought I might be able to pass
command line args to the utility that downloads packages. In
MacPorts what is used to download packages? Is it curl?
It is curl, but I don't think there's a way to pass arbitrary
arguments to it. I'm not even sure whether it's called as a
command-line utility or used as a library. I think if you need
some special functionality to download something, then that
functionality should be built into MacPorts base and made
available via the fetch object, like fetch.ignore_sslcert.
Given that some sites prohibit anything that's not a normal user
agent, it would be really useful to be able to set an argument for
setting the user agent to Mozilla or something similar.
As an example, Cenon can't be downloaded normally:
Dwight:~ brent$ curl http://www.vhf-group.com/vhfInterservice/
download/source/Apple/Cenon-3.82.tar.bz2
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<HTML><HEAD>
<TITLE>403 Forbidden</TITLE>
</HEAD><BODY>
<H1>Forbidden</H1>
You don't have permission to access /vhfInterservice/download/
source/Apple/Cenon-3.82.tar.bz2
on this server.<P>
</BODY></HTML>
But using the useragent argument everything is fine:
Dwight:~ brent$ curl -A Mozilla http://www.vhf-group.com/
vhfInterservice/download/source/Apple/Cenon-3.82.tar.bz2
BZh91AY&SY?!????????????????????
?? f?a
?ڎ???j????,??V?T?P???1??W?^? hր???li^???W?zU?\?|!?1Ka??
ZU*K`-????????wf?????l͙T'=???=>??蘆3z?sEu?`?]z4GPMJ֪??Fc7???@
[.. etc ...]
Hmm. We have a "cenon" port already. And you're right, it fails to
download the archive. It looks like they only deliver the 403
response if the user agent contains "curl". Other random strings work
fine. I would consider the www.vhf-group.com web server broken. They
should not be preventing us from downloading their files just because
our user agent contains "curl".
Presumably the cenon port worked properly when it was most recently
committed, so they must have broken their server some time after that.
Adding a "fetch.user_agent" option would be a huge help.
I'm inclined not to like that idea. I'm not sure if I can explain why.
We had a user agent problem before, where a server delivered a silly
response if no user agent was set:
http://trac.macports.org/projects/macports/ticket/7563
This was fixed with MacPorts 1.4.0 when we started sending the user
agent "MacPorts libcurl/[libcurl version]". There was a request in
the log message for r22771 that if someone knows how to put the
MacPorts version number in there, we should do that too, and I agree.
Perhaps it's time to advertise ourselves as Mozilla. Something like:
Mozilla/5.0 MacPorts/1.5.0
It's a bit silly, I know, but I like it better than allowing port
authors to override the user agent.
The best solution, of course, would be for them to fix their server.
Have you already asked them to?
_______________________________________________
macports-users mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo/macports-users
