c# HttpWebResponse en-Tête de l'encodage

J'ai le problème suivant. - Je contacter une adresse que je connais utilise une redirection 301.

à l'aide de HttpWebRequest loHttp = (HttpWebRequest)WebRequest.Create(lcUrl);
et loHttp.AllowAutoRedirect = false; de sorte que je ne suis pas redirigé.

Maintenant, je reçois l'en-tête de la réponse afin d'identifier les nouvelles url.

à l'aide de loWebResponse.GetResponseHeader("Location");

Le problème est que depuis cette url contient des caractères grecs la chaîne renvoyée est tout mélangés (due à l'encodage).

L'intégralité de l'image codewise:

HttpWebRequest loHttp = (HttpWebRequest)WebRequest.Create(lcUrl);
loHttp.ContentType = "application/x-www-form-urlencoded";
loHttp.Method = "GET";

Timeout = 10000;

loHttp.AllowAutoRedirect = false;
HttpWebResponse loWebResponse = (HttpWebResponse)loHttp.GetResponse();

string url= loWebResponse.Headers["Location"];
Par défaut HttpWebRequest va suivre les redirections, donc si un serveur envoie 301/302 code de statut une nouvelle demande sera émis pour aller chercher de la ressource à l'aide de la Location en-tête. Donc, une fois que cette dernière ressource est extraite, il n'y aura plus un Location tête dans la réponse, alors je me demande comment se fait-il qu' loWebResponse.GetResponseHeader("Location") retourne rien d'autre qu'une chaîne vide. Cela mis à part, avez-vous vérifié avec FireBug que le site effectue un encodage correct sur le Location en-tête?
Je n'ai pas préciser que " loHttp.AllowAutoRedirect = false;' est réglé afin que je puisse inspecter l'url de redirection

OriginalL'auteur Alexandros B | 2009-12-11

  1. 6

    Si vous laissez le comportement par défaut (loHttp.AllowAutoRedirect = true) et votre code ne fonctionne pas (il n'est pas redirigé vers la nouvelle ressource), cela signifie que le serveur n'est pas codant pour la Location en-tête correctement. Est la redirection de travail dans le navigateur?

    Par exemple, si l'url de redirection est http://site/Μία_Σελίδα l'Emplacement de l'en-tête doit ressembler à http://site/%CE%95%CE%BD%CE%B9%CE%B1%CE%AF%CE%BF_%CE%94%CE%B5%CE%.

    Mise à JOUR:

    Après une enquête plus poussée sur la question, je commence à soupçonner qu'il y a quelque chose étrange avec HttpWebRequest. Lorsque la demande est envoyée au serveur envoie la réponse suivante:

    HTTP/1.1 301 Moved Permanently
Date: Fri, 11 Dec 2009 17:01:04 GMT
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
Location: http://www.site.com/buy/κινητή-σταθερή-τηλεφωνία/c/cn69569/
Content-Length: 112
Content-Type: text/html; Charset=UTF-8
Cache-control: private
Connection: close
Set-Cookie: BIGipServerpool_webserver_gr=1007732746.36895.0000; path=/


<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">

    Comme nous pouvons le voir Location en-tête contient des caractères grecs qui ne sont pas codées dans l'url. Je ne suis pas sûr si c'est valable en fonction de la Spécification HTTP. Ce que nous pouvons dire pour sûr, c'est qu'un navigateur web, l'interprète correctement.

    Voici la partie intéressante. Il semble que HttpWebRequest ne pas utiliser l'encodage UTF-8 pour analyser les en-têtes de réponse parce que lors de l'analyse de la Location en-tête il donne: http://www.site.com/buy/κινηÏή-ÏÏαθεÏή-ÏηλεÏÏνία/c/cn69569/, ce qui est évidemment faux et quand il essaie de rediriger vers cet endroit que le serveur répond avec une nouvelle redirection et ainsi de suite jusqu'à ce que le nombre maximum de redirections est atteint et qu'une exception est levée.

    Je ne pouvais pas trouver n'importe quel moyen de spécifier l'encodage utilisé par HttpWebRequest lors de l'analyse des en-têtes de réponse. Si nous utilisons TcpCLient manuellement il fonctionne parfaitement bien:

    using (var client = new TcpClient())
{
    client.Connect("www.site.com", 80);

    using (var stream = client.GetStream())
    {
        var writer = new StreamWriter(stream);
        writer.WriteLine("GET /default/defaultcatg.asp?catg=69569 HTTP/1.1");
        writer.WriteLine("Host: www.site.com");
        writer.WriteLine("User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.2) Gecko/20090805 Shiretoko/3.5.2");
        writer.WriteLine("Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8");
        writer.WriteLine("Accept-Language: en-us,en;q=0.5");
        writer.WriteLine("Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7");
        writer.WriteLine("Connection: close");
        writer.WriteLine(string.Empty);
        writer.WriteLine(string.Empty);
        writer.WriteLine(string.Empty);
        writer.Flush();

        var reader = new StreamReader(stream);
        var response = reader.ReadToEnd();
        //When looking at the response it correctly reads 
        //Location: http://www.site.com/buy/κινητή-σταθερή-τηλεφωνία/c/cn69569/
    }
}

    Donc je suis vraiment intrigué par ce comportement. Est-il possible de préciser le type de codage utilisé par HttpWebRequest? Peut-être certains d'en-tête doit être réglé?

    Comme une solution de contournement, vous pouvez essayer de modifier le asp page qui effectue la redirection et urlencode la Location en-tête. Par exemple, lorsque dans un ASP.NET l'application vous effectuez une Response.Redirect(location), l'emplacement sera automatiquement html codé et non caractères standard seront convertis en leurs entités correspondantes.

    Par exemple si vous n': Response.Redirect("http://www.site.com/buy/κινητή-σταθερή-τηλεφωνία/c/cn69569/"); dans un ASP.NET application de la Location en-tête sera fixé à : 

    http://www.site.com/buy/%ce%ba%ce%b9%ce%bd%ce%b7%cf%84%ce%ae-%cf%83%cf%84%ce%b1%ce%b8%ce%b5%cf%81%ce%ae-%cf%84%ce%b7%ce%bb%ce%b5%cf%86%cf%89%ce%bd%ce%af%ce%b1/c/cn69569

    Il semble que ce n'est pas le cas avec l'ASP classique.

    si je le laisse à true, alors j'obtiens une exception (soit un délai d'attente ou un maximum de redirections exception). Dans le navigateur, il fonctionne bien en termes de parvenir à la bonne page. Donc je suppose que je suis en train de faire quelque chose de mal dans la lecture de l'Emplacement des en-têtes.
    Est-il possible que vous pouvez poster l'URL pour que je puisse prendre un coup d'oeil? Ou peut-être qu'il n'est pas accessible au public?
    Dans .Net, l'analyse des en-têtes est traitée dans un "pur ASCII" encoding qui est encapsulé à l'intérieur de la WebHeaderCollection classe. Ceci est en conformité avec la RFC 2616. Celui de la remise que l'Emplacement de l'en-tête est de FAIRE le MAL, mais la plupart des navigateurs "simplement y faire face", en supposant que le jeu de caractères UTF-8 (ce qui est dans le flux d'octets).

    OriginalL'auteur Darin Dimitrov

  2. 1

    Je ne voudrais pas que la chaîne de retour à difformes...comment allez-vous déterminer qu'il est mal formé? La chaîne doit être dans un format unicode comme utf-8, ce qui serait en mesure de représenter le grec chaîne facilement.

    Il se pourrait que vous n'avez tout simplement pas le grec pour représenter la chaîne?

    par malformés, je veux dire, pas lisible une fois l'encodage. c'est ce que le getResponseHeader renvoie "site.com/buy/..."
    hmmm dans visual studio, il semble un peu différent :S mais toujours comme vous le voyez, la partie du milieu est en ruine

    OriginalL'auteur John Weldon

  3. 1

    Que Darin Dimitrov explique, je crois que l'en-tête de codage est provoqué par un bogue dans la classe HttpWebResponse. Nous avons eu le même problème lorsque nous avons voulu ajouter un cookie dans l'en-tête (Set-Cookie) et ce témoin contiennent des caractères non-Ascii. Dans notre spesific cas ce serait le norvégien lettres 'Æ', 'Ø' et 'Å' (majuscules et minuscules). Nous ne pouvions pas comprendre comment obtenir le HeaderEncoding de travail, mais nous avons trouvé une façon de contourner à l'aide de Base64-encodage du cookie. Noter que cela ne fonctionne que si vous êtes dans le contrôle à la fois le client et côté serveur (ou vous pouvez convaincre les gens en charge de la partie serveur de code pour ajouter le codage Base64 pour vous...)

    Sur le côté serveur:

    var cookieData = "This text contains Norwegian letters; ÆØÅæøå";
var cookieDataAsUtf8Bytes = System.Text.Encoding.UTF8.GetBytes(cookieData);
var cookieDataAsUtf8Base64Encoded = Convert.ToBase64String(cookieDataAsUtf8Bytes);
var cookie = new HttpCookie("MyCookie", cookieDataAsUtf8Base64Encoded);
response.Cookies.Add(cookie);

    Sur le côté client:

    var cookieDataAsUtf8Bytes = Convert.FromBase64String(cookieDataAsUtf8Base64Encoded);
var cookieData = System.Text.Encoding.UTF8.GetString(cookieDataAsUtf8Bytes);

    Noter que cookieDataAsUtf8Base64Encoded sur le côté client est la partie données du cookie ("Moncookie=[données]", où " Moncookie=' est dépouillé).

    OriginalL'auteur Kjetil Klaussen