- 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
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
caching?
- 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 :-).
HTH,
Alex.
--
| 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