Ignore MisbehavingServers rather than fail with an error

[Ryan Schmidt]

On Apr 8, 2012, at 22:34, Joshua Root wrote:

> On 2012-4-8 21:42 , Ryan Schmidt wrote:
>> 
>> I find it rude and upsetting that you reverted my change rather than initiating a continuation of this thread yourself.
> 
> I felt similarly about what appeared to be an attempt to sneak the
> change into the release over my objections. Clearly we both
> misinterpreted. I apologise for any poor communication on my part.

Ok, apology accepted. I certainly didn't want to "sneak" anything into the release. That's why I brought the issue up on the list in January. And since I didn't think the discussion had produced any objections, when talk began about doing a release soon, I wanted to make sure this change made it in because I'm tired of dealing with the tickets.


On Apr 8, 2012, at 22:40, Joshua Root wrote:

> The patch doesn't report a misbehaving server in this case, it makes
> fetching fail for no discernable reason.

That is true, and I'm open to suggestions on how we could improve MacPorts so that a helpful error is reported. However, I would not tie it to this discussion about non-RFC-compliant DNS servers; rather, I'd say if MacPorts fails to fetch a distfile from *all* available master_sites, then a special error message could be printed about checking your Internet connection or proxy settings.

Lion and later, and iOS, include a feature where they check http://www.apple.com (or some Apple page) and if they don't receive the expected response, they assume it's a public wifi situation that you have to log into, so they open a web browser window for you to do that. We might consider having MacPorts do something similar -- not necessarily open a web browser, since we're not a GUI, but at least detect if a known-good site like http://www.macports.org can be reached, and if not, inform the user. We could cache the result of that check, just like we cache the ping time results now.


> Applying restrictions to what distfiles may contain before you even know
> that the checksums don't match is an incorrect approach.

Ok, what's the correct approach?

My solution may be a bit of a hack, but it worked for me and solved the problem I was trying to solve. If you know of a situation where it doesn't work, let me know.

As I've said before, the problem I want to solve is that users who have RFC-ignoring DNS servers should not be punished for that. I may not like those DNS servers, but I'm often at locations where those DNS servers are used; I don't have a choice about that and I don't want MacPorts punishing me for it; I want MacPorts to just continue and try another server and work properly, just as it would if an RFC-compliant DNS server were used. Whatever we have to do to make that happen, I'm all ears.