You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@apr.apache.org by jo...@apache.org on 2004/06/22 22:08:03 UTC

cvs commit: apr-util/include apr_buckets.h

jorton      2004/06/22 13:08:03

  Modified:    include  apr_buckets.h
  Log:
  * include/apr_buckets.h: Remove some vapourware.
  
  Revision  Changes    Path
  1.157     +0 -11     apr-util/include/apr_buckets.h
  
  Index: apr_buckets.h
  ===================================================================
  RCS file: /home/cvs/apr-util/include/apr_buckets.h,v
  retrieving revision 1.156
  retrieving revision 1.157
  diff -d -w -u -r1.156 -r1.157
  --- apr_buckets.h	13 Feb 2004 09:55:26 -0000	1.156
  +++ apr_buckets.h	22 Jun 2004 20:08:03 -0000	1.157
  @@ -701,17 +701,6 @@
                                                   apr_off_t point,
                                                   apr_bucket **after_point);
   
  -#if APR_NOT_DONE_YET
  -/**
  - * consume nbytes from beginning of b -- call apr_bucket_destroy as
  - * appropriate, and/or modify start on last element 
  - * @param b The brigade to consume data from
  - * @param nbytes The number of bytes to consume
  - */
  -APU_DECLARE(void) apr_brigade_consume(apr_bucket_brigade *b,
  -                                      apr_off_t nbytes);
  -#endif
  -
   /**
    * Return the total length of the brigade.
    * @param bb The brigade to compute the length of
  
  
  

Re: cvs commit: apr-util/include apr_buckets.h

Posted by Joe Orton <jo...@redhat.com>.
On Tue, Jun 22, 2004 at 03:31:57PM -0500, William Rowe wrote:
> BLECK!
> 
> Ok this is my 'fault'.  Please note that EXACTLY this proposed code exists
> and is used in the ssl core filter of httpd.
> 
> Before you go blasting to smithereens, could we please discuss the merits
> of this approach?  It's clear that every brigade application at some point
> will FINALLY consume the brigade, and apr-util aught to be the standard
> of how this is done, not each and every arbitrary application.

No comment on usefulness of theoretical apr_brigade_consume itself, but
adding random crap to headers is not the way to track such issues,
exactly because you'll forget all about it for three years and nobody
else will notice it either.  Either add a note to STATUS or file an RFE
in bugzilla if you think this is useful and don't want to forget about
it.

joe

Re: cvs commit: apr-util/include apr_buckets.h

Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
BLECK!

Ok this is my 'fault'.  Please note that EXACTLY this proposed code exists
and is used in the ssl core filter of httpd.

Before you go blasting to smithereens, could we please discuss the merits
of this approach?  It's clear that every brigade application at some point
will FINALLY consume the brigade, and apr-util aught to be the standard
of how this is done, not each and every arbitrary application.

In the SSL case, although the data isn't transmitted over the wire, it is
slurped, exactly as much as is useful at that moment, and then destroyed
as it has been crypted into a SSL bytestream for the wire.  Persisting any
of those plaintext buckets (except obviously any immortal buckets) after 
the crypt operation becomes a memory hog.  

Are we leaving this up to each and every app to reinvent?  Any thoughts?

Bill

At 03:08 PM 6/22/2004, jorton@apache.org wrote:
>jorton      2004/06/22 13:08:03
>
>  Modified:    include  apr_buckets.h
>  Log:
>  * include/apr_buckets.h: Remove some vapourware.
>  
>  Revision  Changes    Path
>  1.157     +0 -11     apr-util/include/apr_buckets.h
>  
>  Index: apr_buckets.h
>  ===================================================================
>  RCS file: /home/cvs/apr-util/include/apr_buckets.h,v
>  retrieving revision 1.156
>  retrieving revision 1.157
>  diff -d -w -u -r1.156 -r1.157
>  --- apr_buckets.h     13 Feb 2004 09:55:26 -0000      1.156
>  +++ apr_buckets.h     22 Jun 2004 20:08:03 -0000      1.157
>  @@ -701,17 +701,6 @@
>                                                   apr_off_t point,
>                                                   apr_bucket **after_point);
>   
>  -#if APR_NOT_DONE_YET
>  -/**
>  - * consume nbytes from beginning of b -- call apr_bucket_destroy as
>  - * appropriate, and/or modify start on last element 
>  - * @param b The brigade to consume data from
>  - * @param nbytes The number of bytes to consume
>  - */
>  -APU_DECLARE(void) apr_brigade_consume(apr_bucket_brigade *b,
>  -                                      apr_off_t nbytes);
>  -#endif
>  -
>   /**
>    * Return the total length of the brigade.
>    * @param bb The brigade to compute the length of
>  
>  
>