Thread: FreeDB cant connect

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.

I'm not sure if this is useful information, but I got an HTTP protocol failure with 095 beta 1. I have no problem to connect to FreeDB with foobar2000 v0.8.3, so i think the problem lies within EAC.

Oops! I need to correct what I said earlier in my lengthy post about HTTP/1.1. EAC has always used HTTP/1.0 GET requests, and somehow I confused myself while I was testing things out using telnet to port 80. I tried typing in HTTP/1.1 GET requests manually, and I think after doing this for a few hours in the middle of the night, I imagined that EAC was doing the same. My apologies for suggesting that the GET requests were not properly formatted.

That said, I think moving to HTTP/1.1 requests would still help solve a lot of the freedb connection issues. CDex also doesn't work when I try to use http, but if I change it's configuration to use cddbp instead, then I have no problems. Also, typing in the IP address of my ISP's proxy in either EAC or CDex allows the freedb stuff to work fine over http.

EAC is the only program I have problems with connecting to Freedb. After reading everything here, the thing that made sense is that EAC is probably sending out malformed HTTP requests. Added to the fact that I'm behind a corporate proxy server, I simply went and entered a transparent public proxy IP into the F12 dialog box, and it works now!

I can only summise that this is an EAC problem since every other program I've tried works fine without an external proxy!

i also that this problem with other extracting softwares ; in fact i usually cope with it by extending the time during the software tries to conect the freedb server ; nevertheless this seems impossible with EAC... or am i wrong ?

I've had this error problem with freedb, but found it was down to interfering third party apps - our proxy server (MS ISA) has an anti-virus scanner inline with it, and this is somehow affecting the traffic between EAC and freedb. I use Tag&Rename to manage my MP3s and it uses freedb to check album info, but doesn't get affected by that issue.
Have faith though, Andre - i tried to download a .NET component from MS the other day and that was being killed by the exact same issue!

The solution (only effective if you have to set a port number for proxy) is to change to a port that bypasses any problem of that nature.

I tied all solutions, but nothing changed(. I think CDDB must working, best grabber with bad CDDB. Now i use CDEX to get data from CDDB to local base, EAC get this from this folder - this is better then cdplaer.ini because u don't need to enter fields Year & Genre. You need to use one local CDDB folder for CDEX and EAC, but i don't recomend you use CDEX & EAC in one time, sometimes it falls and u need to restart Winda (i use WinXP Pro SP2). So i recomend to enter CDEX, catch CD info, close CDEX, open EAC, riping)

Hey!
I have been fooling around with the stuff for a while now, since i neither could connect to freedb. I found that if i started EAC THROUGH! another program, sutch as Total Commander i coulden't connect. But it works every time i start EAC from either the start menu or desktop.

Hope that helps others too...

Murdock

The solution works for EAC and for CDEx:

Enter the email address 'test@t.com' in settings for freeDB access and both application works without problems.

I have also checked 'test@abc.com' and it works also but the email address 'xyz@gmx.net' doesn't run!

I hope the solution works also for you!

Stevie

Since foobar connects to freedb with no problem, I went into the preferences to see how it was set up. The server in the foobar preferences is:

http://freedb.freedb.org/~cddb/cddb.cgi

When I paste that into EAC it tells me that is an invalid server address. Like many others, EAC is the only app I have that cannot connect to freedb. It only happens at work, so I'm sure our network has something to do with it.

I also couldn't connect to freedb through EAC and hear is what I found to be the problem. I had ZoneAlarm installed but stopped using it when I added a hardware firewall. I didn't uninstall it though. Any new program or even updated program coul not access the internet. So EAC wouldn't but WinAmp could due to when the programs were installed. What really messed me up is I re-loaded WMP , Firefox, and MusicBrainz and NONE of them could access the internet. I almost re-loaded Windows but woke up at two in the morning with the idea of checking ZoneAlarm. As soon as I started ZA and launched any of the problem apps including EAC I was prompted to allow or disallow internet access for that program. After checking the boxes to allow that program to access the internet ALL of the apps worked correctly. So at least in my case ZA was the offending app even though it was not being used or loaded at start-up.

Use this proxy
195.245.185.18 port 80

and this url
http://freedb.freedb.org:80/~cddb/cddb.cgi

and this email
abc@abc.com

I just created a new profile and it worked.

Hi there!

It seems that this is a sort of neverending thread.
I just spent 2 days reading everything I could find about EAC and freedb connetctions.

I had the problem that everytime I tried to connect to a freedb server with my laptop in a privat wlan environment, my system crashed with a blue screen. I remember that someone else also discribed a similar problem here.

I finally figured out a solution and I want you to know

My system used an intel 2200bg proset Wireless driver which seem to cause some interrupt probs with certain programs (w22n51.sys version 8.12.9000). I updated the driver from the intel page (version 9.x) and now everything works perfect.

I am using win xp s2 on a toshiba notbook.

Btw, I'm also using zonealarm but this was never a problem.

Hope that helps.

So happy that I can continue to use this marvelous program with full freedb support ;-) Thanx Andre!