C#: Manejo de la "violación de protocolo" de WebClient

Question

Necesito leer una ubicación en mi enrutador, pero obtengo la siguiente excepción:

ServerProtocolViolation "The server committed a protocol violation.
Section=ResponseHeader Detail=CR must be followed by LF"

Esto ocurre cuando uso la función .DownloadString(url) . ¿Hay alguna manera de hacer que WebClient ignore la violación del protocolo? Las búsquedas en Google me dicen que debo configurar la opción useUnsafeHeaderParsing algún lugar. ¿Puedo hacerlo a través del programa? ¿Cuál es el problema si lo uso?

Editar: Adjuntando código -

 public Readlog() {
WebClient wc = new WebClient();
string url = @"http://192.168.0.1/setup.cgi?next_file=log.htm&todo=cfg_init";
Console.WriteLine(url);
try {
//wc.Headers.Add("User-Agent", "Mozilla/5.0(Windows; U; Windows NT 5.2; rv:1.9.2) Gecko/20100101 Firefox/3.6");
wc.Credentials = new NetworkCredential("admin", "admin");
//Next line causes exception System.Net.WebException
//Message - "The server committed a protocol violation. Section=ResponseHeader Detail=CR must be followed by LF"
//May be I need to use useUnsafeHeaderParsing somehow to avoid that
string result = wc.DownloadString(url);
Console.WriteLine(result);
} catch (WebException we) {
System.Diagnostics.Trace.WriteLine(we.ToString());
}
}

Answer 1

Parece que la forma más fácil es incluir un archivo .config con su aplicación que contenga lo siguiente:

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

Sin embargo, también es posible hacerlo dentro del código, pero parece un poco desordenado:

http://social.msdn.microsoft.com/Forums/en-US/netfxnetcom/thread/ff098248-551c-4da9-8ba5-358a9f8ccc57

También tenga en cuenta que la definición de MSDN de esa propiedad es

La configuración de esta propiedad ignora los errores de validación que se producen durante el análisis HTTP.

http://msdn.microsoft.com/en-us/library/system.net.configuration.httpwebrequestelement.useunsafeheaderparsing.aspx

Así que diría que es bastante seguro de usar, aunque sí menciona que solo se usa para la compatibilidad con versiones anteriores.

Answer 2

Tuve este problema en mi propio servidor web, en el encabezado cambié

HTTP/1.x 200 OK

a

HTTP/1.0 200 OK

ahora funciona cuando uso un navegador (chorome o ...) o en WebClient (c #)