Des Herriott
- desht
- desht
- Europe/Stockholm
- Yes
- No
1 issues
Key
Summary
Status
Reporter
Assignee
Created
MCL-4Changed Description:
See also
MC-431, which was wrongly closed as "not a bug".There is indeed a bug in the launcher, as a quick decompile of the launcher JAR shows. See this code around line 454 of GameUpdater, in the downloadJars() method:
str1 = localURLConnection.getHeaderField("ETag"); str1 = str1.substring(1, str1.length() - 1);The code blindly assumes that the HTTP response header always contains an ETag field, which is not necessarily true. This tag is often stripped by HTTP proxies.
Very easily fixed by adding a "if (str1 != null)" test to line 454 (note that str1 is later compared with null in the method so it's safe to continue with it set to null).
There is indeed a bug in the launcher, as a quick decompile of the launcher JAR shows. See this code around line 454 of GameUpdater, in the downloadJars() method:
str1 = localURLConnection.getHeaderField("ETag"); str1 = str1.substring(1, str1.length() - 1);The code blindly assumes that the HTTP response header always contains an ETag field, which is not necessarily true. This tag is often stripped by HTTP proxies.
Very easily fixed by adding a "if (str1 != null)" test to line 454 (note that str1 is later compared with null in the method so it's to continue with it set to null).
18 days later and this is it?! This is not resolved.
It's very clear that your code isn't using any proxies. It's just blindly assuming that an ETag header is present in one part of downloadJars() (and thus throwing an NPE if it isn't), even though it later tests for it. So it's internally inconsistent for a start.
Any in any case, can you name which standard, exactly, is violated by a proxy stripping an ETag header? I'll ignore the hyperbolic use of "tons of standards", I'd just like one standard, please. Don't bother mentioning RFC 2068; although it states that a proxy MUST NOT modify ETag headers, it says nothing about removing them.
Finally: even if this were a standards violation, users behind such proxies often don't make a conscious decision to use them. Are you going to penalise them in such a petty fashion just for having a computer in the wrong place? All it takes to fix the problem is a simple one-line null comparison (which, as I said, you do anyway a few lines further down in the method).
I see ticket
MC-431was again wrongly closed, this time as an invalid report. Please don't just close this ticket for the same reason. See my comment inMC-431for why.I disagree that it's clear that proxies must not remove these headers. It explicitly states that they must not be modified or added. Think about it for a minute: an ETag is effectively a checksum on the resource being requested/sent. It's very bad if a proxy adds or changes an ETag that the client already has cached, since this could result in an updated file not getting pulled when it should be. But if there's no ETag at all, the worst result is that a new file is sent when not strictly required, since the client doesn't have any cached ETag to check with the server. Extra use of network bandwidth, yes, but the data transferred remains valid.
The RFC does not state that ETag headers must not be removed. That text you quoted also specifically refers to transparent proxies, which does not include application-layer proxies that the client explicitly connects to. Transparent proxies rewrite requests at the network layer, and the client has no way of knowing that such a proxy is even present. (When I tested, I was using an application layer proxy by passing command-line options to the JVM).
But in any case, I'm glad you agree that the fix is trivial. And since you check for the presence of ETag headers later in the very same method anyway, it's clear that someone at some point wrote the code to correctly handle the case where an ETag is not provided. So you will lose nothing by fixing this problem, and gain a few more satisfied users. It really is a no-brainer.