vidéo Stream Windows Media Player sur http

Question

Essayer de flux vidéo sur windows media player d'un servlet (style de téléchargement progressif). Le streaming fonctionne, mais j'ai un comportement étrange, que je voudrais exclure n'est pas causé par un problème dans ma mise en œuvre. Lorsque vous utilisez WMP pour ouvrir une URL à partir du servlet, WMP va effectuer un total de 4 requêtes http-get pour la même ressource, mais avec des en-têtes légèrement différents à chaque fois. La connexion pour les 3 premières demandes semble être fermée dès que la requête (y compris les en-têtes) a été envoyée. La quatrième requête reste connectée et je peux réellement fournir les en-têtes de réponse et le contenu du fichier.

ont essayé d'utiliser Wireshark pour regarder les trois premières demandes. Des démarrages identiques des réponses sont envoyés pour les 4 demandes, et les 3 premières demandes ont réussi à envoyer les en-têtes de réponse, et une partie du contenu du fichier avant d'être fermé. (Je ne sais pas si son pertinente, mais doivent permettre « support de paquets capture du matériel compatible TSO IP » pour Wireshark pour analyser correctement le flux, sinon le premier paquet contenant le http-réponse est considérée comme malformé.)

les 4 têtes de requête ci-dessous ici:

GET /basic/test.mpg HTTP/1.1 
Accept: */* 
User-Agent: Windows-Media-Player/12.0.7600.16415 
Accept-Encoding: gzip, deflate 
Host: 192.168.1.34 
Connection: Keep-Alive 

GET /basic/test.mpg HTTP/1.1 
Cache-Control: no-cache 
Connection: Keep-Alive 
Pragma: getIfoFileURI.dlna.org 
Accept: */* 
User-Agent: NSPlayer/12.00.7600.16385 WMFSDK/12.00.7600.16385 
GetContentFeatures.DLNA.ORG: 1 
Host: 192.168.1.34 

GET /basic/test.mpg HTTP/1.1 
Accept: */* 
User-Agent: NSPlayer/12.00.7600.16385 WMFSDK/12.00.7600.16385 
Icy-Metadata: 1 
Accept-Encoding: gzip, deflate 
Host: 192.168.1.34 
Connection: Keep-Alive 

GET /basic/test.mpg HTTP/1.1 
Cache-Control: no-cache 
Connection: Keep-Alive 
Pragma: getIfoFileURI.dlna.org 
Accept: */* 
User-Agent: NSPlayer/12.00.7600.16385 WMFSDK/12.00.7600.16385 
GetContentFeatures.DLNA.ORG: 1 
Host: 192.168.1.34 

têtes de réponse:

HTTP/1.1 200 OK 
Content-Type: video/mpeg 
Content-Length: 130549760 
ETag: TEST1286565215430 
ContentFeatures.DLNA.ORG: DLNA.ORG_PN=MPEG_PS_PAL;DLNA.ORG_OP=00 
Server: Jetty(6.1.x) 

Answer 1

la connexion pour les 3 premières demandes semble être fermé dès que la demande (y compris les en-têtes) ont été envoyé.

"Semble être"? Je voudrais savoir pour certain d'une façon ou avant de procéder. S'il met fin à la connexion après que les en-têtes de réponse ont été définis, il se peut que le lecteur s'attendait à ce qu'un en-tête très spécifique soit présent. Des exemples pourraient inclure Range: ou Cache-Control:.