Skip to content
  1. Sep 29, 2001
    • Justin Erenkrantz's avatar
      Input filtering rewrite. Consolidate how we handle HTTP input parsing by · 27677a43
      Justin Erenkrantz authored 
      rearranging and rethinking some things.  The net result is that the HTTP
filter is now a request filter and is now only responsible for HTTP things.
The core input filter is now responsible for handling all of the dirty work.

Highlights:
- Removes the dechunk filter and merges it with ap_http_filter (aka HTTP_IN).
  The dechunk filter was incorrectly handling certain cases (trailers).
- Moves ap_http_filter from a connection filter to a request filter
  to support the consolidation above (it needs header info).
- Change support code to allow the http_filter to be a
  request filter (how the request is setup initially).
- Move most of the logic from HTTP_IN to CORE_IN (core_input_filter).
  HTTP_IN is now only concerned about HTTP things.  The core filter
  is now responsible for returning data.  It is impossible to
  consolidate dechunk and http without this because HTTP_IN previously
  buffered data.  As Greg has suggested, it may make sense to write
  some brigade functions that handle input (getline).  It should be
  fairly trivial to add these.  Some of the calls in ap_http_filter
  could be switched as well.

This is the original patch as submitted to dev@httpd on Monday, Sep.
24th.  Additional comments and some minor tweaks done after that
submission are coming up next.  This should allow people who reviewed
the original patch to see what has changed and review them piecemeal.

This test passes all current tests in httpd-test.  Please perform
chicken sacrifices to verify that this hasn't blown up your favorite
input.

Reviewed by:	Greg Stein, Ryan Bloom, and Cliff Woolley (buckets)


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@91189 13f79535-47bb-0310-9956-ffa450edef68
      27677a43
    • Justin Erenkrantz's avatar
      Fix for httpd-test modules/include test #17. · bed39e1a
      Justin Erenkrantz authored 
      If we are *already* a faux URI (i.e. relative file sub req) and we then
make a subrequest from that faux URI to a file in the same directory,
we'd try to build a URI out of the fake URI which leads to the wrong
thing happening somewhere down the line.  So, let's just give this
special case a fake URI as well.

OtherBill needs to verify this.  He can back it out if he wants.  I
don't much care.  It's one line and it seems okay...


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@91187 13f79535-47bb-0310-9956-ffa450edef68
      bed39e1a
  3. Sep 28, 2001
  5. Sep 27, 2001
  7. Sep 26, 2001
  9. Sep 25, 2001
  11. Sep 24, 2001
  13. Sep 23, 2001
  15. Sep 22, 2001