- 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