[Bram77]

My problem is kind of hard to describe in the title... so here's the full description.

I'm writing a media controller for the XBMC xbox version in C++. It will be a Winamp-like tool that will make it possible to control what is playing on the XBOX like you are playing it locally on your windows pc. I've just started and I've already spend some day's figuring out what is going wrong. It's most likely a problem with the library I'm using to do http request, but maybe someone here can give me some insight in the reason why it's not working as you'd expect.

I'm using the Indy Sockets lib, which is great, to do the requests. It works pretty straight forward. I open en a url with a Get request and the method returns the content of the page in string... i.a.

Code:

AnsiString pageContent =  IdHTTP1->Get("http://<xbox-ip>/xbmcCmds/xbmcHttp?command=GetCurrentlyPlaying");

Now I can open every page I want on the xbox or the internet and the "pageContent" var will contain the source of the requested page. Except for the pages I need! So if I request the "http://<xbox-ip>/default.asp" page, it will return the content of the webinterface perfectly. But no matter what command I run on "http://<xbox-ip>/xbmcCmds/xbmcHttp?command=" ..... it returns an empty string..... always. Even though when I request the exact same page with my browser I get the result you'd expect. I really don't get it.

Can anyone help me understand what the problem is?

[Bram77]

Using C# with WebRequest results in the following error...

Code:

The server committed a protocol violation. Section=ResponseStatusLine

And the source...

Code:

private void button1_Click(object sender, EventArgs e)
        {
            WebRequest request        = WebRequest.Create("http://10.1.1.156/xbmcCmds/xbmcHttp?command=GetCurrentlyPlaying");
            request.Credentials       = CredentialCache.DefaultCredentials;
            HttpWebResponse response  = (HttpWebResponse)request.GetResponse();
            textBox1.Text             = response.StatusDescription;
            Stream dataStream         = response.GetResponseStream();
            StreamReader reader       = new StreamReader(dataStream);
            string responseFromServer = reader.ReadToEnd();
            richTextBox1.Text         = responseFromServer;
            reader.Close();
            dataStream.Close();
            response.Close();
        }

Using Visual C++ with WebRequest results in the following error...

Code:

An unhandled exception of type 'System.Net.WebException' occurred in System.dll

Additional information: The server committed a protocol violation. Section=ResponseStatusLine

And the source...

Code:

private: System::Void button1_Click(System::Object^  sender, System::EventArgs^  e) {
                   WebRequest^ request = WebRequest::Create( "http://10.1.1.156/xbmcCmds/xbmcHttp?command=SetVolume&parameter=40" );
                   request->Credentials = CredentialCache::DefaultCredentials;
                   HttpWebResponse^ response = dynamic_cast<HttpWebResponse^>(request->GetResponse());
                   textBox1->Text = response->StatusDescription;
                   Stream^ dataStream = response->GetResponseStream();
                   StreamReader^ reader = gcnew StreamReader( dataStream );
                   reader->ReadLine();
                   reader->ReadLine();
                   String^ responseFromServer = reader->ReadToEnd();
                   richTextBox1->Text = responseFromServer;

                   reader->Close();
                   dataStream->Close();
                   response->Close();
             }
    };

I can't seem to find a solution to this problem. The conclusion is that it's not the Indy Sockets library that's causing the error. The headers send by the xbox are the trouble makers (correct me if I'm wrong).
I guess this is a problem that more people have encountered. Anyone any suggestions?

[matt_cyr]

try setting
useUnsafeHeaderParsing="true"
in your .config file under
<system.net>
<settings>
useUnsafeHeaderParsing="true"

[Bram77]

I came across that solution while searching. But where can I find the web.conf file?

[matt_cyr]

you're not building a web application so you would have to add it to the app.config i would guess. Should be in your project folder

[Bram77]

I've figured out how to add a App.config file (Project->Add New Item->Application Configuration File). Thanks! This error is fixed, so it seems.

Now I've got a new error "The underlying connection was closed: The connection was closed unexpectedly.". Starting to fix this now

[Bram77]

This one seems a bit harder to solve...
All the solutions I find are proxy and firewall related. I don't use a proxy server or a firewall, so that can't be the cause if this.

[Bram77]

I think I've discovered something.

XBMC is returning inconsistent data.
For example.....

Sometimes the "GetVolume" command returns....

Code:

<html><li>64</html>

Where "64" obviously is variable. This is what I'd expect XBMC to return at all times.
But most of the time XBMC returns only....

Code:

64

Which results in a error in C# and C++

Code:

The underlying connection was closed: The connection was closed unexpectedly.

....somehow.

In a browser these results look like you'd expect (tested with Chrome, Firefox3 and IE7).
The fist case has a dot before the "64" (* 64), the second one simply shows "64".

Is there anything I can do to fix this in XBMC (help debug or something...).

[Bram77]

As I mentioned before, opening and reading web files works perfectly. A page doesn't need <html> tags to be opened with the HttpWebRequest. If I create a .asp file containing a single line of plain-text all goes well. There error only occurs when opening the "http://<xbox-ip>/xbmcCmds/xbmcHttp" file. It seems like the connection is closed from the server side and no matter what method I use in C++ or C#. I've spend hours (and hours, and hours) trying to figure out how to get around this problem. But it seems impossible without changes on the xbox server.

[rwparris2]

Not that I know anything about C++ or C#, but can't you just try to parse <html><li>64</html>, if error look for 64?

[Bram77]

Thank you for your reply.

If XBMC isn't returning "<html><li>64</html>", I can't fetch anything from the page the XBOX returned. Somehow the XBOX tells my app that the connection has been closed before the "64" has been written to the web page. I know it still is returning "64" because I can check in a browser.

[matt_cyr]

Are you using the latest version of XBMC? also, what platform?
I've been trying to get the same results as you and I cannot.
I always get <html><li>40</html> (which in itself is horrible html imho)

Are you getting these funky results (different html) in the webbrowser as well? or just in your code?

[Bram77]

I'm running the latest T3CH build on the XBOX.

If I get "64" (without the html parts) in the browser, a GET request from C++/C# results in a "The underlying connection was closed: The connection was closed unexpectedly." exception and a empty stream. If the browser is showing the result WITH html code, I don't get the exception.

[matt_cyr]

Hmmm, I can't seem to reproduce it here. I am running Windows XBMC but I'd think the api would be the same.
have you tried getting the output in a different format at all? using SetResponseFormat?
you can get the output in more of an xml style.
or run SetResponseFormat with no options to reset back to default and see if that helps.

[rwparris2]

Can't reproduce it here either, on T3ch's beta1 build for xbox or beta1 on windows, using port 80 with no password protection.

I wrote a script that grabbed it 5000 times on each platform and each time it was <html><li>66</html>

Are you using a funky port perhaps? Password protection?

The only thing I can think to suggest is to do like matt_cyr said and run http://xbmcIP/xbmcCmds/xbmcHttp?command=...onseformat before the rest of your code to make sure everything is set to default.

I tried turning off the webheaders and <li> to replicate what you got, and google chrome complained about the webserver being offline (yet it would open a simple .html file with nothing but '66' inside), so making sure everything is set correctly is your best bet IMO.