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
