Lorsque vous faites une demande à l'aide de l'objet httpwebrequest, je dois appeler la méthode getResponse () pour envoyer la demande et récupérer la réponse.
Le problème avec cette méthode est qu'il ne renvoie pas l'objet de réponse tant que toutes les données n'ont pas été reçues. Dis que je télécharge un fichier de 100 Mo, je ne pourrai pas le lire tant que la fin de la réponse est téléchargée.
Ce que je veux, c'est pouvoir lire les octets de réponse de réponse dès qu'ils arrivent, sans attendre la réponse à compléter.
Je sais que je peux utiliser l'en-tête HTTP de la plage, mais cela ne fonctionnera pas sur ma situation.
4 Réponses :
Si vous définissez la taille de la mémoire tampon sur votre lecture, vous pouvez lire dans les données dans les morceaux ... Exemple ...
// Get the response stream
using(Stream resStream = response.GetResponseStream())
{
string parseString = null;
int count = 0;
do
{
// Read a chunk of data
count = resStream.Read(buf, 0, buf.Length);
if (count != 0)
{
// Convert to ASCII
parseString = Encoding.ASCII.GetString(buf, 0, count);
// Append string to results
sb.Append(tempString);
}
}
while (count > 0);
}
Ceci est après la fin de la réponse, je souhaite pouvoir lire le flux de réponses avant cela.
Je pense que c'est très proche de ce que suggère @zachary. Et il (semble) travail (s); En fait, je pense qu'u En outre, le code suivant montre à peu près comment tout fonctionne; il ne lit pas le flux à la fin par exemple (sauf par coïncidence :)). Mais cela devrait fonctionner si vous copiez-la-nez-la-coller dans une «application de la console» vide dans Visual Studio. Vous pouvez essayer d'utiliser une URL "plus courte" pour un test. L'exemple ici commence ici à télécharger une ISO de la distribution de Debian (un peu plus de 600 Mo). Désolé Debian, je ne voulais pas voler votre bande passante. -> BTW: Y a-t-il quelque chose de sensible que l'on peut utiliser pour tester un tel scénario? Le code est fortement inspiré par < Un href = "https://stackoverflow.com/questions/775574/c-how-to-read-a-continu-stream-of-xml-over-http"> C # - Comment lire un flux continu de XML sur Http . en utilisant car @zachary fait est même "plus gentil".
Mon point principal étant que je ne peux pas voir le comportement de blocage de getResponse () vous (semblez) décrire.
Idem ... que Scherand a dit :)
Je ne suis pas sûr de ce que vous avez de votre côté, mais je sais un fait (et je suis sûr que beaucoup de gens seront d'accord ici) que Après avoir eu la réponse, vous pouvez facilement obtenir le flux de réponses avec Si vous n'obtenez pas le même comportement (qui est vraiment étrange, et ne devriez pas arriver) Pourriez-vous ajouter un exemple de code qui ne fonctionne pas comme je l'ai expliqué ci-dessus?
En outre, testez l'exemple posté par SCHERAND . Cela prouve simplement une fois de plus qu'il fonctionne très bien, sans aucun hack particulier. getResponse () ne téléchargera pas tout le fichier arrière. Il enverra la demande, attendra la réponse et obtenez les en-têtes de réponse.
getResponsestream () , qui est le flux de données réel qui télécharge à partir du serveur. Et vous pouvez facilement accéder au flux de réponses avant que l'ensemble du fichier ne soit téléchargé. Ceci est 100% vrai et testé.
Je cherchais la même chose: Streams Server des données XML a besoin de données XML et j'avais besoin d'un client C # pouvant accéder à ces données lorsque le serveur est en streaming. J'ai essayé de nombreuses façons différentes d'accéder à la source (Webchannelfactory, webclient, httpwebrequest / réponse, tcpclient) mais échoué jusqu'à présent. Trouver ce fil je me suis concentré sur httpwebrequest / réponse où j'ai le même problème que la ligne suivante est bloquée: comme artiom chilaru indiqué, s'il s'agit de bloquer: quelque chose ne va pas, car il ne faut pas. Maintenant, concentrez-vous sur la possibilité de répliquer le comportement par défaut avec le téléchargement de gros fichiers .iso que j'ai découvert que le violonau bloquait la méthode GetResponse ()! Cependant, il n'y a aucun problème à ouvrir Fiddler une fois que le flux a été configuré (c.-à-d. GetResponse () a déjà été appelé), mais lors de l'obtention de HTTP si vous trouvez GetResponse () bloque Essayer de fermer FiMdler et voir si votre application est maintenant continue, il s'agit d'un flux normal (c'est-à-dire lire le flux).
C'était exactement mon problème. Une fois que j'ai fermé Fiddler GetResponse () s'est comporté comme prévu. Merci!
Je sais que c'est un vieux fil, mais ajoute mes 2 cents. Fiddler est en fait un serveur proxy, de sorte que la réponse du serveur d'origine puisse réellement la réponse du serveur d'origine, puis fait ce que vous attendez. C'est pourquoi son blocage.
GetResponse () ou le rappel que vous fournissez à la bégayeResponse () sont appelés dès que tous les en-têtes de réponse sont lus, mais toute la réponse ne sera pas lu que si elle n'est pas vraiment petite ou que vous le lisez.
Pas clair si l'OP a effectivement testé l'une des solutions suggérées et confrontée à des problèmes spécifiques. Dans mon expérience, obtenir le flux de réponses ne reçoit que le flux et que vous lisez à partir de ce flux, la réponse est téléchargée, à moins bien sûr que ce n'est un petit morceau!