Details
-
Bug
-
Status: Closed
-
Major
-
Resolution: Fixed
-
4.1.3
-
None
Description
We're using HttpClient to check the validity of links on our site, and lately users have been reporting that working links are incorrectly flagged as invalid. Looking into the problem, I find that it all boils down to us using code somewhat like this:
import java.io.IOException;
import org.apache.http.client.HttpClient;
import org.apache.http.client.methods.HttpGet;
import org.apache.http.impl.client.DefaultHttpClient;
public class BadRequest {
public static void main(String[] args) {
try
catch (IOException e)
{ e.printStackTrace(); } }
}
Compiling and running the above example with HttpClient 4.1.3 results in a 400 code (20 April in 2012).
Specifically in the following exchanges:
GET /KK3231/syllabus/ HTTP/1.1
Host: www.edu.mah.se
Connection: Keep-Alive
User-Agent: Apache-HttpClient/4.1.3 (java 1.5)
HTTP/1.1 301 Moved Permanently
Content-Type: text/html; charset=UTF-8
Location: http://edu.mah.se/sv/Course/KK3231#Syllabus
Server: Microsoft-IIS/7.5
X-Powered-By: PHP/5.3.9
X-Powered-By: ASP.NET
Date: Fri, 20 Apr 2012 12:33:40 GMT
Content-Length: 315
GET /sv/Course/KK3231#Syllabus HTTP/1.1
Host: edu.mah.se
Connection: Keep-Alive
User-Agent: Apache-HttpClient/4.1.3 (java 1.5)
HTTP/1.1 400 Bad Request
Content-Type: text/html; charset=us-ascii
Server: Microsoft-HTTPAPI/2.0
Date: Fri, 20 Apr 2012 12:33:40 GMT
Connection: close
Content-Length: 324
I do realize that according to the HTTP 1.1 standard, the location header returned by the server is invalid.
However, all browsers seem to be able to handle a redirection like this. Thus I can hardly tell users that the error is on the server side when they can paste it into any browser and get a working page. So I was wondering if you would consider adapting to the current state of things and perhaps strip fragments from redirect URIs?