httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Harrie Hazewinkel <har...@covalent.net>
Subject Re: cvs commit: apr/network_io/unix sendrecv.c
Date Mon, 26 Feb 2001 20:24:21 GMT
Greg Stein wrote:
[snip]
> >   Log:
> >   Begin to move functions from the http module to the core.  The goal is to
> >   have only functions that are HTTP specific in the http directory.
[snip]
> >   const char *ap_make_content_type(request_rec *r, const char *type)
> 
> Content-Type is HTTP-specific.

Other protocols have content types too, not even the way it goes into
the HTTP response. During my IETF involvement I have seen various
protocols using this. For instance the iCalendar Message-Based
Interoperability Protocol (iMIP) uses it. Just think is most
cases of protocol that are more or less derived from HTTP.

> 
> >...
> >   static int parse_byterange(char *range, apr_off_t clength,
> >                              apr_off_t *start, apr_off_t *end)
> >...
> 
> All the byterange stuff is HTTP-specific.

FTP has a similar concept. The REST command where a specific
byte-range of a accessed resource (file) is required. Simply
said, REST should turn the rest portion of a file
 
> >...
> >   AP_DECLARE(void) ap_set_content_length(request_rec *r, apr_off_t clength)

This is NOT HTTP specific. Not even the way it goes into
the HTTP response is. Other protocols use an equal approach.
Seen, for instance, in emails sometimes.

> >   AP_DECLARE(char *) ap_make_etag(request_rec *r, int force_weak)
> >...
> >   AP_DECLARE(void) ap_set_etag(request_rec *r)
> 
> HTTP-specific.

ETags are HTTP specific. So far I have not seen them somewhere else.

> >...
> >   AP_CORE_DECLARE(int) ap_getline(char *s, int n, request_rec *r, int fold)
> 
> HTTP-specific. This understands the HTTP header/body mechanism.
> 
> >...
> >   AP_CORE_DECLARE(void) ap_parse_uri(request_rec *r, const char *uri)

Other protocols also do have URIs in there requests.

> >...
> >   static int read_request_line(request_rec *r)

The idea of read_request_line is not HTTP specific, only the
format it will read.

> >...
> >   static void get_mime_headers(request_rec *r)
> 
> HTTP-specific.

Other protocols use MIME too.

> 
> >...
> >   request_rec *ap_read_request(conn_rec *conn)
> 
> Tough one. This is HTTP specific today, so I'd probably say leave it in
> modules/http and create a new, generic request builder in server/protocol.c.
> 
> >...
> >   void ap_set_sub_req_protocol(request_rec *rnew, const request_rec *r)
> 
> Urf. Probably HTTP specific, too.
> 
> >...
> >   AP_DECLARE(void) ap_note_auth_failure(request_rec *r)
> >...
> >   AP_DECLARE(void) ap_note_basic_auth_failure(request_rec *r)
> >...
> >   AP_DECLARE(void) ap_note_digest_auth_failure(request_rec *r)
> >...
> >   AP_DECLARE(int) ap_get_basic_auth_pw(request_rec *r, const char **pw)
> 
> All HTTP specific.

The authentication mechanisms are in most cases not HTTP specific.

> 
> >...
> >   AP_CORE_DECLARE_NONSTD(apr_status_t) ap_content_length_filter(ap_filter_t *f,
> >                                                                 apr_bucket_brigade
*b)

Somehow generic. For instance in the WWW-MIB (SNMP agent) need to
have this information.

> >...
> >   static int ap_set_byterange(request_rec *r)
> 
> HTTP specific again.
> 
> I'm obviously really confused. What is your plan? Are all these HTTP
> functions there only temporarily? I just don't understand...

If I understand the underlying idea. If something that is now
in the HTTP protocol module not really HTTP specific, it goes into
the server (which is the core, right??) I also don't think it is a
bad idea to put generic protocol components into the core server.


Harrie

Mime
View raw message