W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2002

Re: HTTP Stack

From: Alex Rousskov <rousskov@measurement-factory.com>
Date: Tue, 5 Nov 2002 09:03:52 -0700 (MST)
To: srikant.chonnad@siritech.com
cc: ietf-http-wg@w3.org
Message-ID: <Pine.BSF.4.44.0211050837250.34472-100000@measurement-factory.com>

On Tue, 5 Nov 2002 srikant.chonnad@siritech.com wrote:

>      While implementing a HTTP stack, is there a standard interface that
> has to be implemented?

I do not know of any, and I doubt a single standard would be ideal for
the majority of applications. There are many ways to "support" RFC
2616 and, hence, there are many design decisions you have to make:

	- client/server/proxy "side" of your stack; do you
	  need to support all sides or a specific side?
	- how much control do you want the user to have?
	  is the user concerned primarily with sending or
	  receiving content? do they need tight control
	  over content cachability, expiration, types, or
	  even individual HTTP headers?
	- is performance important?
	- is portability important? are code size and memory
	  footprint important?
	- do you need to support caching inside your code?
	  do you need to provide enough hooks for external
	- is ability to act in the middle of an HTTP
	  transaction important? what about on-the-fly
	  content generation and/or modification?
	- is ability to support [external] authentication
	  important? do you need to support "https"?
	- etc.

You do not have to start the design from scratch though. It is a good
idea to study existing interfaces, especially those that are close to
your problem domain. There are several obvious sources of information:
Apache server (performance and flexibility), Squid caching proxy
(caching and flexibility), Jigsaw server (Java), wget and cUrl
clients, as well as related C, C++, and Java libraries that provide
lower-level interfaces. In many cases, the developers would be happy
to consult you on specific design issues they have faced so that you
do not repeat their mistakes.

I would recommend that you strive for HTTP/1.1 compliance from the
start rather than implementing a quick HTTP/1.0 hack in hope to become
compliant later. Based on my experience, that "later" never happens
without a significant and costly rewrite of primary code. Note that
none of the above applications are fully HTTP/1.1 compliant so you
need to be careful when adopting best practices.

Finally, make sure that you really need your own stack and cannot
adopt or wrap an existing library or application :-).



                            | HTTP performance - Web Polygraph benchmark
www.measurement-factory.com | HTTP compliance+ - Co-Advisor test suite
                            | all of the above - PolyBox appliance
Received on Tuesday, 5 November 2002 11:04:27 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:36 UTC