Digital-Inn - View Single Post

11-05-2005

I've been getting "HTTP Protocol Error" messages as well, whether trying to update the server list or query freedb.org for an album. I was able to get it working by figuring out what my ISP's proxy address was, and entering that info in the appropriate boxes. However, this shouldn't be necessary...

Based on what seh mentioned earlier about the HTTP request, I tried looking at the packet trace with Ethereal myself. After reproducing the problem with "telnet <host> 80", I think I see the solution.

EAC 0.95pb5 produces an HTTP request that looks like this:
----
GET /~cddb/cddb.cgi?cmd=<command string> HTTP/1.1
User-Agent: Exact Audio Copy/1.00
----

The problem with this is that it doesn't follow the HTTP spec. Look at RFC 2616 for HTTP/1.1 (http://www.w3.org/Protocols/rfc2616/....html#sec5.1.2):

----
The most common form of Request-URI is that used to identify a resource on an origin server or gateway. In this case the absolute path of the URI MUST be transmitted (see section 3.2.1, abs_path) as the Request-URI, and the network location of the URI (authority) MUST be transmitted in a Host header field. For example, a client wishing to retrieve the resource above directly from the origin server would create a TCP connection to port 80 of the host "www.w3.org" and send the lines:

GET /pub/WWW/TheProject.html HTTP/1.1
Host: www.w3.org
----

Basically what this is saying is that with HTTP/1.1, eac _MUST_ include the "Host: freedb.freedb.org" line in the GET request, otherwise it's not following the protocol. I believe this is what is leading to many of the errors people are getting. Perhaps some people happen to have the right combination of ISP and freedb host so that this incorrect request gets through anyway. In my case my ISP's transparent proxy is intercepting the request before it gets to the freedb server, and since there's no "Host:" line, it rewrites the request to use the proxy as the freedb.org server, and then returns an HTTP error indicating that the URL was not found. It's kind of convoluted, but that's how it is.

So, there are two solutions, but since I still have problems with the first, I think the second one is the best.

A) Change the GET request to use HTTP/1.0, as in:

----
GET /~cddb/cddb.cgi?cmd=<command string> HTTP/1.0
User-Agent: Exact Audio Copy/1.00
----

It seems like this *should* work, and it does when I try it from a local university machine. But when I try it from my home machine, it still fails because my ISP's proxy is doing the same weird address rewriting stuff. Since I'm probably not the only one who would run into the problem, the more correct/useful solution is:

B) Use a proper HTTP/1.1 request:

----
GET /~cddb/cddb.cgi?cmd=<command string> HTTP/1.1
Host: freedb.freedb.org (or whatever host the user configured)
User-Agent: Exact Audio Copy/1.00
----

I'm pretty confident this will drastically reduce the number of people running into problems with freedb queries. Incidentally, I think CDex has the same problem with HTTP requests, but it's crashing on me right now so I can't verify that.

I'll copy this info to the main bug reporting email address. Hopefully this issue can be addressed in a new release soon.

11-05-2005	#181
Chacmool Gast Posts: n/a	I've been getting "HTTP Protocol Error" messages as well, whether trying to update the server list or query freedb.org for an album. I was able to get it working by figuring out what my ISP's proxy address was, and entering that info in the appropriate boxes. However, this shouldn't be necessary... Based on what seh mentioned earlier about the HTTP request, I tried looking at the packet trace with Ethereal myself. After reproducing the problem with "telnet <host> 80", I think I see the solution. EAC 0.95pb5 produces an HTTP request that looks like this: ---- GET /~cddb/cddb.cgi?cmd=<command string> HTTP/1.1 User-Agent: Exact Audio Copy/1.00 ---- The problem with this is that it doesn't follow the HTTP spec. Look at RFC 2616 for HTTP/1.1 (http://www.w3.org/Protocols/rfc2616/....html#sec5.1.2): ---- The most common form of Request-URI is that used to identify a resource on an origin server or gateway. In this case the absolute path of the URI MUST be transmitted (see section 3.2.1, abs_path) as the Request-URI, and the network location of the URI (authority) MUST be transmitted in a Host header field. For example, a client wishing to retrieve the resource above directly from the origin server would create a TCP connection to port 80 of the host "www.w3.org" and send the lines: GET /pub/WWW/TheProject.html HTTP/1.1 Host: www.w3.org ---- Basically what this is saying is that with HTTP/1.1, eac _MUST_ include the "Host: freedb.freedb.org" line in the GET request, otherwise it's not following the protocol. I believe this is what is leading to many of the errors people are getting. Perhaps some people happen to have the right combination of ISP and freedb host so that this incorrect request gets through anyway. In my case my ISP's transparent proxy is intercepting the request before it gets to the freedb server, and since there's no "Host:" line, it rewrites the request to use the proxy as the freedb.org server, and then returns an HTTP error indicating that the URL was not found. It's kind of convoluted, but that's how it is. So, there are two solutions, but since I still have problems with the first, I think the second one is the best. A) Change the GET request to use HTTP/1.0, as in: ---- GET /~cddb/cddb.cgi?cmd=<command string> HTTP/1.0 User-Agent: Exact Audio Copy/1.00 ---- It seems like this should work, and it does when I try it from a local university machine. But when I try it from my home machine, it still fails because my ISP's proxy is doing the same weird address rewriting stuff. Since I'm probably not the only one who would run into the problem, the more correct/useful solution is: B) Use a proper HTTP/1.1 request: ---- GET /~cddb/cddb.cgi?cmd=<command string> HTTP/1.1 Host: freedb.freedb.org (or whatever host the user configured) User-Agent: Exact Audio Copy/1.00 ---- I'm pretty confident this will drastically reduce the number of people running into problems with freedb queries. Incidentally, I think CDex has the same problem with HTTP requests, but it's crashing on me right now so I can't verify that. I'll copy this info to the main bug reporting email address. Hopefully this issue can be addressed in a new release soon.

Sponsored Links