"The server committed a protocol violation" is unoverridable in Metro style apps - by antiufo

Status : 

  By Design<br /><br />
		The product team believes this item works according to its intended design.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.

Sign in
to vote
ID 737000 Comments
Status Closed Workarounds
Type Bug Repros 8
Opened 4/15/2012 11:49:36 AM
Access Restriction Public


I'm writing a Metro style app for listening to web radios.

Some web servers are not fully RFC-compliant, so .NET throws an exception (Protocol violation, ResponseStatusLine), which is not overridable via App.config in Metro style apps.

Please Microsoft, fix this issue, we have to deal with >> REAL-WORLD SERVICES <<, not just with idealized, RFC-compliant servers, and don't make me reimplement HTTP over TCP sockets.

Note that MediaPlayer.set_Source(Uri url) accepts these kind of "malformed" responses, so don't be hypocritical and say that this "useUnsafeHeaderParsing" is dangerous so it's disabled and not available for Metro style apps.
Either you allow both WinRT and .NET handle these responses, or none of them.

I can't use MediaPlayer.set_Source because I need access to the underlying stream, in order to provide recording capabilities.
Sign in to post a comment.
Posted by ncu on 2/13/2014 at 6:28 AM
I have the same problem. Is there already a solution to this problem, could MS please have another look at this? Please have us developers override this feature as in .NET, like manineel008 posted. I have tried using your suggested Sockets APIs, without success, could you point us in the right direction on how to do this? Thanks!
Posted by JerryHuang.net on 1/19/2014 at 7:18 AM
Can I rate this?

In my case it's even worse - I'm an Ip camera app developer. Each Ip camera hosts its own http server, and I'm dealing with various servers developed by various of vendors. Manufacturer like Panasonic uses LF instead of CRLF, and this is NOT a problem in WP7 or WP8.

Posted by Jean-Pierre Sneyers on 12/25/2012 at 6:52 AM
I have the same problem.

no way to reopen this issue ?
Posted by AndreAlvesLima on 7/25/2012 at 12:23 AM
Hi guys,
I am facing the same issue here trying to consume a PHP webservice from a Metro Style App... Is there any workaround for this?
Posted by antiufo on 4/24/2012 at 1:09 PM
I have some news, could you reopen the bug? (I chose the wrong example before)

Look at HackerNews instead: http://news.ycombinator.com/

Every web browser handles it correctly, but .NET throws an exception, because of the LFs instead of CRLFs (pretty common mistake for unix-minded people).

** So, why are our bulletproof browsers allowed to download, parse and execute this kind of "dangerous" things, while .NET isn't even allowed to get the raw content of the response?

Note: Fiddler automatically replaces the LFs with CRLFs, so you won't notice the problem in the hex viewer. Use SmartSniff or Wireshark instead.

A bit of context:
I'm writing a feed reader that can also handle feed-less sites like HackerNews and reddit.
I already have a console app that pre-fetches all the feeds and uploads them to a webserver (as ordinary RSS feeds):

This wouldn't scale well for many users with many feeds, I need to download pages locally, right from the Metro style app (which won't be able to override useUnsafeHeaderParsing).
Posted by Microsoft on 4/23/2012 at 1:50 PM
Despite the obvious "HTTP"-ness of the URI, the "web service" you are trying to connect to is not an HTTP service and is rightly being rejected. The response to the "get" request, for example, should start with "HTTP/1.1 GET..." instead of "ICY 200 OK".

Looking at the result with an assortment of web browsers shows a variety of results ranging from an attempt to display the stream of data to an outright failure.

Using Fiddler to trace the data results in an immediate protocol error being displayed.

Part of the design of the System.Net Http APIs is to prevent security failures that would be created if we succeeded in connecting to such services.

What you can do instead is try to use the Sockets APIs.
Posted by MS-Moderator08 [Feedback Moderator] on 4/16/2012 at 1:23 AM
Thank you for submitting feedback on Visual Studio 11 and .NET Framework. Your issue has been routed to the appropriate VS development team for review. We will contact you if we require any additional information.
Posted by manineel008 on 4/15/2012 at 11:43 PM
After browsing a lot, I could understand that this was resolved in previous versions of .Net by editing app.config file, But in Metro Apps it cannot be done. Please help, I am in same boat and I cannot see in sink..
Posted by MS-Moderator01 on 4/15/2012 at 6:48 PM
Thank you for your feedback, we are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(http://support.microsoft.com)