Amazon Adds New Server Response Header to HTTP Spec

I like it when a major online retailer takes the initiative and extends the existing HTTP specifications.

Date: Fri, 01 Sep 2006 13:58:58 GMT
Server: Server
x-amz-id-1: 1S269NQQQYFX2DF09G7Z
x-amz-id-2: jiSzL7NRwWiEx7pM/90anU1AW9p9Qts3
Set-cookie: session-id-time=1157698800l; path=/; domain=.amazon.com; expires=Fri Sep 08 07:00:00 2006 GMT
Set-cookie: session-id=002-9480265-0783223; path=/; domain=.amazon.com; expires=Fri Sep 08 07:00:00 2006 GMT
Vary: Accept-Encoding,User-Agent
Content-Encoding: gzip
Content-Type: text/html; charset=ISO-8859-1
nnCoection: close
Transfer-Encoding: chunked

Anyone know what the nnCoection: close header represents?

Categories: The Web

2 Comments

  1. This is what I found:
    “Missed Cneonctions
    This header:
    Cneonction: close
    and its variant:
    nnCoection: close
    were two of the headers which first spurred my interest in HTTP headers.
    imdb.com, amazon.com, gamespy.com, and google.com have all at various times used these or similar misspellings of connection, and I’m not by any means the first to have noticed. My first thought was that this was just a typo. After more consideration, however, I now believe this is something done by a hackish hardware load balancer trying to “remove” the connection close header when proxying for an internal server. That way, the connection can be held open and images can be transmitted through the same TCP connection, while the backend web server doesn’t need to be modified at all. It just closes the connection and moves on to the next request. ”
    (from http://www.nextthing.org/archives/2005/08/07/fun-with-http-headers )

  2. This is what I found:”Missed CneonctionsThis header:Cneonction: closeand its variant:nnCoection: closewere two of the headers which first spurred my interest in HTTP headers.imdb.com, amazon.com, gamespy.com, and google.com have all at various times used these or similar misspellings of connection, and I’m not by any means the first to have noticed. My first thought was that this was just a typo. After more consideration, however, I now believe this is something done by a hackish hardware load balancer trying to “remove” the connection close header when proxying for an internal server. That way, the connection can be held open and images can be transmitted through the same TCP connection, while the backend web server doesn’t need to be modified at all. It just closes the connection and moves on to the next request. “(from http://www.nextthing.org/archives/2005/08/07/fu… )

Leave a Reply

Your email address will not be published. Required fields are marked *

five × 1 =

Copyright © 2024 Performance Zen

Theme by Anders NorenUp ↑