httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Life is hard, and then you die" <>
Subject Re: Filter I/O take 3.
Date Fri, 16 Jun 2000 08:01:26 GMT
On Thu, Jun 15, 2000 at 03:52:53PM -0700, wrote:
> This patch enable filtering output.  I have not implemented input
> filtering, because I believe it is trivial once we have the output
> done.
> Issues resolved:
>      Grouping filters by type
>      allocating space on the stack or heap as appropriate
>      memcpy'ing data that is never modified (not done anymore)
>      Send headers after filters have sent the first block of data.
> Issues not resolved:
>      Negative pushback from the network (there is a comment in the code
> for how to implement this)
>      Filters that only deal with half the data.  (the basic idea is there,
> but it is not well tested.  Still working on this).
>      cleanup the code:  some stuff just commented out until it can be
> tested better.
>      insert ap_run_insert_filters for sub_requests???  I'm not sure about
> this.  Maybe we just want to inherit these.
>      Others?  I know there are others, but I can't think of them right
> now.

I just had a quick perusal and missed two things, both of which are
essential for mod_auth_digest to amke any use of filtering at all:

1) being able to set trailers in the response. When using qop=auth-int,
   mod_auth_digest needs to calculate a hash of the entity as it's being
   written, and then needs to put that hash in a trailer which gets sent
   with the last chunk (yes, this doesn't work for HTTP/1.0 clients -
   however, I'm not aware of any HTTP/1.0 clients which do digest auth).

2) Layering on the request body. If a request comes in with qop=auth-int
   then mod_auth_digest needs to be able to calculate a hash of the request
   body. It'll also need to be able to access the trailers in case the
   client put the info in the trailer.

Btw., great to the the grouping by type!



View raw message