httpd-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject cvs commit: httpd-2.0/modules/proxy proxy_http.c
Date Tue, 29 Jun 2004 14:00:08 GMT
martin      2004/06/29 07:00:08

  Modified:    modules/proxy proxy_http.c
  *** Patch for EBCDIC-host and HTTP/0.9 responses only ***
  In dealing with a HTTP/0.9 response to a proxy request, we have pre-read
  data that is not an HTTP header. At this point of processing, we don't
  know yet whether the data is going to be interpreted an binary or not.
  (In fact, we may never find out because HTTP/0.9 lacks the Content-Type
  headers; only by configuring mod_charset_lite can we control the conversion).
  But mod_charset_lite will get control only later, so it cannot decide on
  the conversion of the current buffer full of data.
  => This is an extreme and rare situation normally.
  So, for catching the most obvious problem (talking not to a HTTP server
  but to some other protocol), the best guess here is to treat the buffer
  as "text/*" (to make error messages readable).
  Revision  Changes    Path
  1.188     +10 -0     httpd-2.0/modules/proxy/proxy_http.c
  Index: proxy_http.c
  RCS file: /home/cvs/httpd-2.0/modules/proxy/proxy_http.c,v
  retrieving revision 1.187
  retrieving revision 1.188
  diff -u -u -r1.187 -r1.188
  --- proxy_http.c	29 Jun 2004 06:37:21 -0000	1.187
  +++ proxy_http.c	29 Jun 2004 14:00:07 -0000	1.188
  @@ -1190,6 +1190,16 @@
           /* Is it an HTTP/0.9 response? If so, send the extra data */
           if (backasswards) {
               apr_ssize_t cntr = len;
  +            /*@@@FIXME:
  +             * At this point in response processing of a 0.9 response,
  +             * we don't know yet whether data is binary or not.
  +             * mod_charset_lite will get control later on, so it cannot
  +             * decide on the conversion of this buffer full of data.
  +             * However, chances are that we are not really talking to an
  +             * HTTP/0.9 server, but to some different protocol, therefore
  +             * the best guess IMHO is to always treat the buffer as "text/*":
  +             */
  +            ap_xlate_proto_to_ascii(buffer, len);
               e = apr_bucket_heap_create(buffer, cntr, NULL, c->bucket_alloc);
               APR_BRIGADE_INSERT_TAIL(bb, e);

View raw message