The transfer-length of a message is the length of the message-body as it appears in the message; (...) If a Content-Length header field (section 14.13) is present, its decimal value in OCTETs represents both the entity-length and the transfer-length. The Content-Length header field MUST NOT be sent if these two lengths are different
Seriously, dudes. When one dares to write books where chapters are entitled "users can't read" where you explain how to design GUIs, the same one should prove that *he* does read. And more obviously, when one pretend to ship a web server, the same one should ensure that it actually serves _the_ web and not _what you'd prefer the web to be_. Read the specification snippet above. Read the reply trace below. Any sound heard in your brain ?
En d'autre termes, si la taille du fichier (sur le serveur) et la taille des données envoyées (dans la réponse HTTP) diffèrent, l'en-tête
Content-Length
est interdit. C'est ce qu'il peut y avoir de plus fort dans un RFC qui se contente généralement de "SHOULD" et autres "MAY". Pensiez-vous que ça suffise aux guignols de Redmond ? Eh bien non.13720 recv(12, " HTTP/1.1 206 Partial Content\r\n Content-Type: application/x-zip-compressed\r\n Last-Modified: Mon, 16 May 2011 04:21:42 GMT\r\n Accept-Ranges: bytes\r\n ETag: \"6fe34bc28013cc1:0\"\r\n Server: Microsoft-IIS/7.5\r\n X-Powered-By: ASP.NET\r\n Date: Thu, 09 Jun 2011 17:12:04 GMT\r\n Content-Length: 4000000\r\n Content-Range: bytes 0-3999999/38651711\r\n \r\n PK\3\4\24\0\0\0\10\0n\212;>\204\10\231\20\265\253\25\0 \222\202\26\0\25\0\0\0secret_garden_lrg.jpg\354|y8\324 "..., 8192, 0) = 1368
Voici donc une réponse qui dit à la fois "le fichier fait 4,000,000 bytes" (
Content-Length == Entity-Length
) et "le fichier fait 38,651,711 bytes" (Content-Range
).So the file is both 4,000,000 and 38,651,711 bytes long, right ?
No wonder why you dodged the IPv6 day, eh ?
No comments:
Post a Comment