Re: svn commit: r1711044 - in /httpd/httpd/trunk/modules/http2: h2_io.h h2_mplx.c h2_mplx.h h2_session.c h2_session.h h2_stream.c h2_stream.h h2_task.c h2_task.h h2_task_queue.c h2_task_queue.h h2_ver
On 10/28/2015 04:53 PM, ic...@apache.org wrote: > Author: icing > Date: Wed Oct 28 15:53:07 2015 > New Revision: 1711044 > > URL: http://svn.apache.org/viewvc?rev=1711044&view=rev > Log: > http2 priority based scheduling of stream execution in each session > > Modified: > httpd/httpd/trunk/modules/http2/h2_io.h > httpd/httpd/trunk/modules/http2/h2_mplx.c > httpd/httpd/trunk/modules/http2/h2_mplx.h > httpd/httpd/trunk/modules/http2/h2_session.c > httpd/httpd/trunk/modules/http2/h2_session.h > httpd/httpd/trunk/modules/http2/h2_stream.c > httpd/httpd/trunk/modules/http2/h2_stream.h > httpd/httpd/trunk/modules/http2/h2_task.c > httpd/httpd/trunk/modules/http2/h2_task.h > httpd/httpd/trunk/modules/http2/h2_task_queue.c > httpd/httpd/trunk/modules/http2/h2_task_queue.h > httpd/httpd/trunk/modules/http2/h2_version.h > > Modified: httpd/httpd/trunk/modules/http2/h2_io.h > Modified: httpd/httpd/trunk/modules/http2/h2_mplx.c > URL: > http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/http2/h2_mplx.c?rev=1711044&r1=1711043&r2=1711044&view=diff > == > --- httpd/httpd/trunk/modules/http2/h2_mplx.c (original) > +++ httpd/httpd/trunk/modules/http2/h2_mplx.c Wed Oct 28 15:53:07 2015 > @@ -128,7 +128,7 @@ h2_mplx *h2_mplx_create(conn_rec *c, apr > > m->bucket_alloc = apr_bucket_alloc_create(m->pool); > > -m->q = h2_tq_create(m->id, m->pool); > +m->q = h2_tq_create(m->pool, 23); I thought the answer to the last question was 42 :-). Seriously using a hardcoded value that is not done via a #define with a descriptive name and that is not documented is IMHO bad. > m->stream_ios = h2_io_set_create(m->pool); > m->ready_ios = h2_io_set_create(m->pool); > m->closed = h2_stream_set_create(m->pool); Regards Rüdiger
Re: ap_init_rng / apr_random question
On Tue, Oct 27, 2015 at 8:00 PM, Yann Ylavic wrote: > On Tue, Oct 27, 2015 at 6:57 PM, Eric Covener wrote: >> IIUC, it takes something like 32k of /dev/random to initialize apr_random. >> >> APR_RANDOM_DEFAULT_POOLS*APR_RANDOM_DEFAULT_RESEED_SIZE*APR_RANDOM_DEFAULT_G_FOR_INSECURE >> (32*32*32) >> >> But ap_init_rng() does this with ~4000 8-byte reads of /dev/random. >> >> I am working on a platform where access to the crypto facility >> underneath /dev/random is sometimes audited. Does anyone have any >> hints about whether larger reads from /dev/random would be better >> elsewhere? Or if the startup requirement is really this high for data >> from /dev/random? > > AFAICT, /dev/urandom itself only requires 256 bits (32 bytes) of > (secret) entropy to be secure (cryptographically strong), so I don't > think more would be needed for httpd (or APR). > It seems to me that asking for more than 32 bytes of random bytes by > something like a minute is not very sound (both for the requester AND > the "others"), so IMHO we should really take that into consideration. Addng dev@apr in case anyone with knowledge in this area is only watching there.
Re: svn commit: r1710723 - in /httpd/httpd/trunk: CHANGES modules/cache/cache_util.h
On Tue, Oct 27, 2015 at 1:17 PM, Roy T. Fielding wrote:
> > On Oct 26, 2015, at 11:45 PM, jaillet...@apache.org wrote:
> >
> > Author: jailletc36
> > Date: Tue Oct 27 06:45:03 2015
> > New Revision: 1710723
> >
> > URL: http://svn.apache.org/viewvc?rev=1710723&view=rev
> > Log:
> > RFC2616 defines #rules as:
> > #rule
> > A construct "#" is defined, similar to "*", for defining lists of
> > elements. The full form is "#element" indicating at least
> > and at most elements, each separated by one or more commas
> > (",") and OPTIONAL linear white space (LWS). This makes the usual
> > form of lists very easy; a rule such as
> > ( *LWS element *( *LWS "," *LWS element ))
> > can be shown as
> > 1#element
> >
> > It also defines Linear White Space (LWS) as:
> > LWS= [CRLF] 1*( SP | HT )
> >
> >
> > The actual implementation only accepts SP (Space) and not HT (Horizontal
> Tab) when parsing cache related header fields (i.e. "Vary", "Cache-Control"
> and "Pragma")
>
> Well, to be more accurate: RFC7230 defines these (2616 no longer applies)
> and
> the original algorithm did handle HT. My bet is that someone screwed up an
> automated TAB -> two space conversion and the code change got lost in the
> noise.
>
Interestingly it was only introduced in a recent commit (2 yrs ago) with
the defect,
one might guess that the vi/emacs template did the damage when the text was
pasted in.
See also server.c/protocol.c@920 on trunk, which has the correct HT
handling,
explicitly.
