HTTP Protocol Violation

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Greetings;

When attempting to pull down a particular web page using HttpWebRequest, I
get a "HTTP Protocol Violation Error". I understand this is to do errors from
the web service, but need to pull the page anyways. I do not have access to
modify this page/web server. It is an embedded device. The
solution/workaround I keep finding is to insert the following into
application.exe.config file:

<configuration>
<system.net>
<settings>
<httpWebRequest useUnsafeHeaderParsing="true"/>
</settings>
</system.net>
</configuration>

This, however, has no effect for me. I still get the same error message. I
have tried using my code to pull down different pages, and it works fine. I
am sure my program is using the config file. Does anyone have any idea why
'useUnsafeHeaderParsing="true"' would not work for me, or is there any other
technique I can try? Here is a dump of the communication taking place:

GET /cgi-bin/config HTTP/1.1

User-Agent: Code Sample Web Client

Connection: Keep-Alive

Host: 10.103.130.112



<HTML><PRE>Application Version=6.72
ROM Version=5.85
Platform=WA22A
Ethernet MAC=00:10:40:03:34:cf
Radio 1 Type=Agere
Radio 1 MAC=00:02:2d:6e:05:a0
Secure Available=Yes
Fiber Available=No
FPGA Version=0.14
Software Type=Access Point Enterprise
DHCP Server=No
EAS=No
IONS=No
FlashCard=No
</PRE></HTML>

As ugly as it looks, that is the page i need to be able to pull. Also, I
have version 1.1 SP1 of the .NET framework. Any help would be GREATLY
appreciated!

Best Regards
 
Josh said:
Greetings;

When attempting to pull down a particular web page using
HttpWebRequest, I get a "HTTP Protocol Violation Error". I understand
this is to do errors from the web service, but need to pull the page
anyways. I do not have access to modify this page/web server. It is
an embedded device. The solution/workaround I keep finding is to
insert the following into application.exe.config file:

<configuration>
<system.net>
<settings>
<httpWebRequest useUnsafeHeaderParsing="true"/>
</settings>
</system.net>
</configuration>

This, however, has no effect for me. I still get the same error
message. I have tried using my code to pull down different pages, and
it works fine. I am sure my program is using the config file. Does
anyone have any idea why 'useUnsafeHeaderParsing="true"' would not
work for me, or is there any other technique I can try?

Why should it work in the first place? This "feature" is a work-around
for a potential security hole. Do you send non-HTTP 1.1 compliant HTTP
headers?

Cheers,
 
Joerg Jooss said:
Why should it work in the first place? This "feature" is a work-around
for a potential security hole. Do you send non-HTTP 1.1 compliant HTTP
headers?

Cheers,

It should work because I need it to work to accomplish my project. If you
must know, I have thousands of devices in the field I need create a
management solution for. I'm not going to just "give up" due to the fact that
the web interface is poorly written on the device. It is effective and that's
all that matters for now. The biggest threat to my infrastructure is not HTTP
split attacks; it is the inablility to write this management solution! Could
you please tell me if there is a way to ignore HTTP protocol violations? I
understand the security implications, and need to write this solution anyways.
 
Hi!

If I understand you correctly, the device that you have is not sending valid
HTTP headers, indeed it is not even sending a valid HTTP response header at
all.

If you really want to get this working you should just go with a simple
sockets based solution (use System.Net.Sockets.Socket) to connect to the
device and do the management stuff. Other than that, there is no way to get
HttpWebRequest to read this response.

What I would do is create my own class ( eg: DeviceWebRequest) derived from
WebRequest. In that I would use the Socket class to send the request and
parse the response from the server. This is so that my uplevel application
can use the same interface (WebRequest). So, in future, if this device gets
upgraded to confirm to HTTP/1.0/1.1 specs, you can just change your code to
use HttpWebRequest directly. In fact, if you do this intelligently, you
might not even have to modify code, you can just modify your app config file
to remove the registration for your custom WebRequest class.

--
feroze

-----------------
This posting is provided as-is. It offers no warranties and assigns no
rights.

See http://weblogs.asp.net/feroze_daud for System.Net related posts.
----------------

Josh said:
It should work because I need it to work to accomplish my project. If you
must know, I have thousands of devices in the field I need create a
management solution for. I'm not going to just "give up" due to the fact that
the web interface is poorly written on the device. It is effective and that's
all that matters for now. The biggest threat to my infrastructure is not HTTP
split attacks; it is the inablility to write this management solution! Could
you please tell me if there is a way to ignore HTTP protocol violations? I
understand the security implications, and need to write this solution
anyways.
 
Josh said:
It should work because I need it to work to accomplish my project. If
you must know, I have thousands of devices in the field I need create
a management solution for. I'm not going to just "give up" due to the
fact that the web interface is poorly written on the device.

That's all I've wanted to know. You do send invalid HTTP requests. Ouch.
It is
effective and that's all that matters for now. The biggest threat to
my infrastructure is not HTTP split attacks; it is the inablility to
write this management solution! Could you please tell me if there is
a way to ignore HTTP protocol violations? I understand the security
implications, and need to write this solution anyways.

See Feroze's suggestions.

I'm still doubtful that it's a good idea to violate protocol
specifications unless you have total control of the entire
infrastructure and can make sure all devices/components play along.

Cheers,
 
Back
Top