<div dir="ltr">Yes, using the `<font face="monospace">curl -IL</font>` command to obtain the part of the path I need to extract (which is very slightly different from the web browser URL), did the trick. Thanks! :)<div><br clear="all"><div><div dir="ltr" data-smartmail="gmail_signature"><div dir="ltr"><div>-- </div><div>Jason Liu</div></div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Dec 16, 2021 at 4:29 PM Daniel J. Luke <<a href="mailto:dluke@geeklair.net" target="_blank">dluke@geeklair.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">On Dec 16, 2021, at 4:24 PM, Jason Liu <<a href="mailto:jasonliu@umich.edu" target="_blank">jasonliu@umich.edu</a>> wrote:<br>
> I'm working on a new portfile that has its source stored on sourceforge. MacPorts is having trouble obtaining the tarball, because apparently the mirrors are pointing to the wrong file, and if I put the full URL into `master_sites`, it's unable to find the tarball at all. It seems that sourceforge is using 301 redirects to point to the actual file. If I use the URL with a `curl -L`, the correct file downloads just fine. Is there any way to get MacPorts to follow redirects during the fetch phase? If at all possible, I'd like to avoid manually using curl through a `system` call, but I suppose it could work as a last resort.<br>
<br>
Does this sourceforge example help?<br>
<br>
<a href="https://trac.macports.org/wiki/howto/AvoidRedirects" rel="noreferrer" target="_blank">https://trac.macports.org/wiki/howto/AvoidRedirects</a><br>
<br>
-- <br>
Daniel J. Luke<br>
<br>
</blockquote></div>