Hi Willy, I can only answer your question by saying that other clients that use this protocol but replace ICE/1.0 with HTTP/1.0 have no problem with HAProxy.
It seems that those other clients realized it wasn't a good idea to change that part for no good reason :). I thought I had found a solution when I started playing with reqrep (replace ICE with HTTP) but then I noticed only "valid" HTTP requests were being passed through this operator. Any other ideas? There is no official documentation, but this post http://stackoverflow.com/a/9985297/276949 should give you a brief overview. Martin On Fri, Jun 22, 2012 at 1:37 AM, Willy Tarreau <w...@1wt.eu> wrote: > Hello Martin, > > On Thu, Jun 21, 2012 at 07:49:13PM -0400, Martin Konecny wrote: > > Hello, > > > > The ices protocol is based on HTTP and is used for online streaming. In > the > > early days the specification for this protocol was to use > > > > 1 GET /serv/login.php?lang=en&profile=2 *ICE*/1.0 > > 2 Host: www.mydomain.com > > 3 User-agent: my small browser > > 4 Accept: image/jpeg, image/gif > > 5 Accept: image/png > > > > As you can see, the bolded part is the only difference between this and > > HTTP. I guess the designer realized this was a bone headed move and > almost > > every modern icecast client today uses HTTP in its request header. > However > > I need it to work for older clients as well. > > > > My question is, how can I get haproxy to accept this protocol? "option > > accept-invalid-http-request" doesn't seem to be what I want, and I tried > > using "mode tcp" until I realized I couldn't because my config file uses > > > > use_backend <backend> if <condition> (which requires mode http). > > > > My config file is fairly simple if this helps: > > > > frontend http-in-8001 > > bind *:8001 > > > > acl martin11_master_acl url -i /martin11_master > > use_backend martin11_master if martin11_master_acl > > > > backend martin11_master > > #mode tcp > > server martin11_master 192.168.1.147:8002 > > You won't manage to make it pass through in HTTP mode without modifying > the code. I have a few other questions, what does the response look like ? > Also, does the protocol support content-length, transfer-encoding and > content-encoding ? Does it use the same status codes ? Does it support > metadata only requests (HEAD) ? Does it support metadata only responses > (204, 304) ? Does it support interim responses (100, 101) ? Does it > support any form of keep-alive ? Is it compliant to HTTP/1.0 ? To HTTP/1.1 > ? > > All these questions are very important, because the apparent syntax does > not make a protocol compatible with HTTP. The semantics are much stronger > than that. > > Regards, > Willy > >
