Subject: Re: Http overhead

From: [email-masked]
Date: Thu, 30 Nov 2000 08:47:08 -0500

You have an HTTP response header (around 250 bytes) which goes
in its own segment and then all succeeding data is sent in TCP segments as a
stream of bytes.
No overhead other than the TCP/IP overhead.

     The latest standard (HTTP 1.1) has provisions for compression and "chunked"
transfers
which change this, but I haven't seen these used in any real-world situations
yet.

     Doug...................

---

From: Scott Lawrence <[email-masked]>
Date: Thu, 30 Nov 2000 09:16:47 -0500

> which change this, but I haven't seen these used in any real-world situations

Chunked encoding is frequently used in situations where the server 
might not know the size of the response body at the time it is 
generating headers.  This is often the case for CGI and other 
dynamic interfaces.

If chunked encoding is used, there is a short chunk header that 
preceeds each chunk - no more than 10 bytes; the chunk size is up to 
the server, but is typically either the record size of the buffer it 
is using to read the dynamic content, or the buffer size of its 
network buffers (depending on which memory it is optimizing for).

-- 
Scott Lawrence      Architect            [email-masked]
Virata       Embedded Web Technology    http://www.emweb.com/

---

From: John Stracke <[email-masked]>
Date: Thu, 30 Nov 2000 10:45:08 -0500

[email-masked] wrote:

> transfers which change this, but I haven't seen these used in any real-world
> situations
> yet.

Apache will recognize a file with a ".gz" extension as gzipped, and send the
Content-Encoding: x-gzip line.  Netscape will recognize Content-Encoding: x-gzip,
and uncompress the file.  Unfortunately, at least in my installation (Apache
1.3.14, Red Hat 7), Apache doesn't look at the extension before the ".gz" to get
the content-type; "foo.txt.gz" gets marked as Content-Type: application/x-gzip.

--
/=================================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.   |
|Chief Scientist |================================================|
|eCal Corp.      |But how do we know destroying the Van Allen belt|
[email-masked]|will kill all life on Earth if we don't try it? |
\=================================================================/

---

From: "Joris Dobbelsteen" <[email-masked]>
Date: Thu, 30 Nov 2000 17:16:20 +0100

Many apache servers send data chunked. Takes a couple bytes (average of
4) for every block transfered. Maybe a total overhead of an additional
20-40 bytes per transfer (maybe less). This is just a guess...

- Joris

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday 30 November, 2000 14:47
> To: Patrik Carlsson
> Cc: [email-masked]
> Subject: Re: Http overhead
> 
> 
> 
> 
>

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 30 Nov 2000 10:11:39 -0800

Almost all modern browsers support content-encoding (gzip, for example), and
most servers can be pummelled into serving compressed content; actually,
I've seen a lot of activity around this recently, with vendors releasing
products to faclilitate compression on the server, or to move it to an
intermediary. 

While not many Web sites are using compression, the number is growing, and
I've heard rumors of some Big sites playing with it on home pages, etc.
(haven't checked recently).

I've also heard rumors that browsers are starting to support
transfer-encoding.

<plug>see http://www.mnot.net/cgi_buffer/</plug>

On Thu, Nov 30, 2000 at 08:47:08AM -0500, [email-masked] wrote:
> 
> 
> 
>      You have an HTTP response header (around 250 bytes) which goes in its
> own segment and then all succeeding data is sent in TCP segments as a
> stream of bytes. No overhead other than the TCP/IP overhead.
> 
>      The latest standard (HTTP 1.1) has provisions for compression and
> "chunked" transfers which change this, but I haven't seen these used in
> any real-world situations yet.
> 
>      Doug...................
> 
> 

-- 
Mark Nottingham
http://www.mnot.net/