Comment faire pour gérer correctement client “Connection: close” demande sur l'adresse HTTP du serveur de fichiers?

Comment puis-je gérer correctement un client Connection: close demande? À compter de maintenant, si je reçois ce domaine particulier, je ferme le socket et d'attendre une suite à la demande du client que de répondre à nouveau et commencer à servir les données.

Je ne sais pas pourquoi ma communication client/serveur ne fonctionne pas comme le Serveur Apache, j'ai testé avec.

Merci pour les précisions...

Client/Serveur de comunication:

CLIENT:
HEAD /stream.mpeg HTTP/1.0
Host: 127.0.0.1
User-Agent: SuperPlayer
Connection: Close

SERVER:
HTTP/1.0 200 OK 
Date: Wed, 1 Jun 2011 20:05:13 GMT
Server: HTTP Server
Last-Modified: Mon, 06 Aug 2009 01:02:23 GMT
Accept-Ranges: bytes
Connection: Close
Content-Type: audio/mpeg

CLIENT:
HEAD /stream.mpeg HTTP/1.0
Host: 127.0.0.1
User-Agent: SuperPlayer
Connection: Close

SERVER:
HTTP/1.0 200 OK 
Date: Wed, 1 Jun 2011 20:05:13 GMT
Server: HTTP Server
Last-Modified: Mon, 06 Aug 2009 01:02:23 GMT
Accept-Ranges: bytes
Connection: Close
Content-Type: audio/mpeg

231489172304981723409817234981234acvass123412323
21312hjdfaoi8w34yorhadl4hi8rali45mhalo3i,wmotw
345fqw354aoicu43yocq2i3hr

Client/ApacheServer Comunication:

CLIENT:
GET /test.mp3 HTTP/1.0
Host: 192.168.1.120
User-Agent: SuperPlayer
Connection: Close

SERVER:
HTTP/1.1 200 OK
Date: Wed, 01 Jun 2011 19:15:11 GMT
Server: Apache/2.2.16 (Win32)
Last-Modified: Thu, 29 Apr 2010 21:06:34 GMT
ETag: "14000000047049-4f75c8-4856680636a80"
Accept-Ranges: bytes
Content-Length: 5207496
Connection: close
Content-Type: audio/mpeg

...d.....<).0.. ..........<.@.. ( .h.$.J...1...i....A. ......c....a.9..!g.N...A. ........ ....>......|.......8....a......|..|N.............'>[email protected] .e...r.iL..#..IH...pR|.

OriginalL'auteur Jona | 2011-06-01

http java

5

Oui la fermeture de la socket est la bonne action à prendre. Si le client est à l'aide de cet en-tête correctement, ils sont de la fermeture de la socket sur leur fin, une fois qu'ils recevoir votre réponse.

Ce que je constate ici, c'est que votre serveur n'est pas le retour d'un Content-Length en-tête. Même si le client émet une requête HEAD, basé sur la proposition du W3C (sec. 9.4):

La meta-information contenue dans le site HTTP
les en-têtes de réponse à une requête HEAD
DOIT être identique à l'information
envoyé en réponse à une requête GET.
Cette méthode peut être utilisée pour l'obtention de
meta-information au sujet de l'entité
implicite par la demande sans
transférer le corps de l'entité elle-même.
Cette méthode est souvent utilisée pour les tests
des liens hypertextes pour la validité, l'
l'accessibilité, et la récente
la modification.

La réponse d'un CHEF de demande PEUT être
pouvant être mis en cache dans le sens que l'
les informations contenues dans la réponse
PEUT être utilisé pour mettre à jour précédemment
entité du cache à partir de cette ressource. Si
le nouveau champ des valeurs indiquent que l'
entité du cache diffère de l'actuel
entité (comme indiqué par une
changement du Contenu de Longueur, Content-MD5,
ETag ou de Dernière modification), puis le cache
DOIT traiter l'entrée de cache comme obsolète.

La clé ici est de assurez-vous que vous dites au client, de la taille de la réponse sans transmettre les données.

Ah! Je n'avais pas remarqué la TÊTE et se. Bien sur mon serveur HTTP, j'ai lu la TÊTE et les requêtes GET, mais je ne suis pas sûr pourquoi, lorsque j'ai utilisé le serveur Apache et la saisie des données avec Wireshark, je n'ai pas la TÊTE à la demande... Peut-être en quelque sorte Wireshark ne l'a pas saisie?
En fait je retire ce que! Oui, Wireshark a bien lu la requête HEAD... 🙂
Je suis ignorant le champ de longueur sur la fin. Merci pour votre post, j'ai remarqué qu'il y avait effectivement une différence sur le client deux demandes. Une TÊTE et d'autres. Maintenant, je suis capable de lire et de traiter correctement la demande du client.
L'en-tête signifie simplement fermer la connexion après l'envoi de la réponse.
c'est la première chose que je dis dans ma réponse. Comment est-ce la peine d'un downvote, à votre avis?

OriginalL'auteur AJ.
3

La Connexion: à proximité de l'en-tête signifie simplement que le client attend de vous pour fermer la connexion après l'envoi de la réponse. Aussi absout vous d'avoir à envoyer un Content-Length: en-tête.

OriginalL'auteur user207421
2

Puis-je vous demander pourquoi êtes-vous à l'aide de http 1.0 dans la demande?
Il n'y avait pas les connexions persistantes en http 1.0, de sorte que le serveur est censé mettre fin à la connexion TCP après la réponse, si vous envoyez Connection: close ou pas.

Oui, vous avez raison, je devrais le laisser comme http 1.1 pour laisser le client sait je soutiens connexion persistante.

OriginalL'auteur alexrs
2

Si vous utilisez HTTP 1.0, il n'y a pas de connexions persistantes comme alexrs pointu, au lieu de cela, Connection: keep-alive est utilisé avec HTTP 1.0. Sur HTTP 1.1, vous n'avez pas besoin de cela, car les connexions HTTP persistantes par défaut sur HTTP 1.1.

8.1.2 Fonctionnement Global

Une différence significative entre HTTP/1.1 et versions antérieures de HTTP
c'est que les connexions persistantes sont le comportement par défaut de tout HTTP
connexion. C'est, à moins d'indication contraire, le client DOIT
supposons que le serveur sera de maintenir une connexion permanente, même
après les réponses d'erreur du serveur.

Les connexions persistantes de fournir un mécanisme par lequel un client et un
le serveur peut signaler la fermeture d'une connexion TCP. Cette signalisation se
place à l'aide de la Connexion de champ d'en-tête (article 14.10). Une fois qu'un proche
il a été signalé, le client ne DOIT PAS envoyer de plus en plus de demandes sur ce
connexion.

Vous pouvez prendre un coup d'oeil à la HTTP 1.1 RFC;

RFC pour HTTP 1.1

OriginalL'auteur Levent Divilioglu

Vous devez vous connecter pour publier un commentaire.