requête HTTP, comportement étrange socket

Question

Je ressens un comportement étrange lorsque vous faites des requêtes HTTP à travers les sockets, ici la demande:

POST https://example.com:443/service/XMLSelect HTTP/1.1
Content-Length: 10926
Host: example.com
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 1.0.3705)
Authorization: Basic XXX
SOAPAction: http://example.com/SubmitXml

Par la suite, il va corps de ma demande avec une longueur de contenu donné. Après que je reçois quelque chose comme:

HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Content-Type: text/xml;charset=utf-8
Transfer-Encoding: chunked
Date: Tue, 30 Mar 2010 06:13:52 GMT

Donc, tout semble être bien ici. Je lis tout le contenu de flux de réseau et de recevoir avec succès une réponse. Mais ma prise que je fais vote sur les commutateurs, il est des modes comme ça:

write ( i write headers and request here )
read ( after headers sent i begin to receive response )
write ( STRANGE BEHAVIOUR HERE. WHY? here i send nothing really )
read ( here it switches to read back again )

deux dernières étapes peuvent répéter plusieurs fois. Je veux donc demander ce qui conduit pour le changement de mode de prise? Et dans ce cas, ce n'est pas un gros problème, mais quand j'utilise la compression gzip dans ma demande (aucune idée de la façon dont il est lié) et demander au serveur d'envoyer une réponse gzip à moi comme ceci:

POST https://example.com:443/service/XMLSelect HTTP/1.1
Content-Length: 1076
Accept-Encoding: gzip
Content-Encoding: gzip
Host: example.com
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 1.0.3705)
Authorization: Basic XXX
SOAPAction: http://example.com/SubmitXml

Je reçois une réponse comme ça:

HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Content-Encoding: gzip
Content-Type: text/xml;charset=utf-8
Transfer-Encoding: chunked
Date: Tue, 30 Mar 2010 07:26:33 GMT

2000
�

Je reçois une taille de bloc et tête GZIP, il est tout d'accord. Et voici ce qui se passe avec ma pauvre petite prise quant à lui:

write ( i write headers and request here )
read ( after headers sent i begin to receive response )
write ( STRANGE BEHAVIOUR HERE. And it finally sits here forever waiting for me to send something! But if i refer to HTTP I don't have to send anything more! )

Que peut-il être lié à? Qu'est-ce qu'il me veut envoyer? Est-ce problème de serveur web distant ou dois-je raté quelque chose?

PS Toutes les références réelles de service et login / mots de passe remplacés par des faux:)

Answer 1

Un socket devient inscriptible chaque fois qu'il ya de la place dans la prise envoyer tampon . Le système d'exploitation ne peut pas vraiment savoir si votre application a plus de données à envoyer, mais connaît ses structures internes, comme des tampons de socket. Vous devez ajouter / supprimer explicitement la prise à la fd_set d'écriture pour select(2) (activer / désactiver événement EPOLLOUT pour epoll(4)). Cela est généralement traitée avec machine d'état , comme dans libevent . Aussi fonctionne mieux avec vote non bloquante prises.

Hope this helps.