Re: svn commit: r1765368 - in /httpd/httpd/branches/2.4.x: ./ docs/manual/mod/mod_proxy_html.html.en docs/manual/mod/mod_proxy_html.xml

2016-10-17 Thread Daniel Shahaf 
Eric Covener wrote on Mon, Oct 17, 2016 at 16:33:36 -0400:
> On Mon, Oct 17, 2016 at 4:22 PM, Jacob Champion  wrote:
> > On 10/17/2016 01:15 PM, jchamp...@apache.org wrote:
> >>
> >> Log:
> >> Merge r1765361 from trunk:
> >
> >
> > Copy-pasted the wrong rev; this should have been r1765357. Sorry, first time
> > merging...
> 
> For straightforward backports some of us use:
> http://people.apache.org/~jorton/svn.merge

Subversion uses a cron job that automatically merges STATUS entries that
have received sufficient votes.  It creates commits such as this:

https://svn.apache.org/r1765006

Re: svn commit: r1765368 - in /httpd/httpd/branches/2.4.x: ./ docs/manual/mod/mod_proxy_html.html.en docs/manual/mod/mod_proxy_html.xml

2016-10-17 Thread Jacob Champion 

On 10/17/2016 01:33 PM, Eric Covener wrote:

For straightforward backports some of us use:
http://people.apache.org/~jorton/svn.merge


Awesome, thanks for the tip!

--Jacob

Re: svn commit: r1765368 - in /httpd/httpd/branches/2.4.x: ./ docs/manual/mod/mod_proxy_html.html.en docs/manual/mod/mod_proxy_html.xml

2016-10-17 Thread Eric Covener 
On Mon, Oct 17, 2016 at 4:22 PM, Jacob Champion  wrote:
> On 10/17/2016 01:15 PM, jchamp...@apache.org wrote:
>>
>> Log:
>> Merge r1765361 from trunk:
>
>
> Copy-pasted the wrong rev; this should have been r1765357. Sorry, first time
> merging...

For straightforward backports some of us use:
http://people.apache.org/~jorton/svn.merge

Re: svn commit: r1765368 - in /httpd/httpd/branches/2.4.x: ./ docs/manual/mod/mod_proxy_html.html.en docs/manual/mod/mod_proxy_html.xml

2016-10-17 Thread Jacob Champion 

On 10/17/2016 01:15 PM, jchamp...@apache.org wrote:

Log:
Merge r1765361 from trunk:


Copy-pasted the wrong rev; this should have been r1765357. Sorry, first 
time merging...


--Jacob

Using memcached w/ socache

2016-10-17 Thread Jim Jagielski 
Before I start digging into the code to try to figure this
out, has anyone use the memcache socache module to use
memcached as the backend storage for mod_cache? I'm trying
to figure out exactly *how* to configure this...

I'm guessing it's something like

  CacheEnable socache
  CacheSocache memcache:memcached.example.com:7888,foocache.example.com:

but who knows IIRC, using shmcb is like:

  CacheEnable socache
  CacheSocache shmcb:/var/tmp/foo.shm(512000)

so I'm figuring by analogy thats how memcache is.

[PATCH 60223] non-empty OpenSSL error queue preventing non-blocking reads through mod_ssl

2016-10-17 Thread Paul Spangler 

Hello,

Due to the way OpenSSL stores errors in a per-thread queue, functions 
such as SSL_read followed by SSL_get_error may not produce the desired 
result if the error queue is not empty prior to calling SSL_read[1]. For 
example, a non-blocking read reports that no data is available by 
setting up SSL_get_error to return SSL_ERROR_WANT_READ. But if an error 
is already present in the queue, SSL_get_error sees that error instead 
and returns SSL_ERROR_SSL.


I found at least one case where the error queue may be non-empty prior 
to a non-blocking read[2] that involves combining mod_session_crypto 
(which leaves the error queue non-empty) and the third-party 
mod_websocket (which uses non-blocking reads), resulting in the 
connection being closed. I included a potential patch to mod_ssl for 
consideration on the bug report that simply clears the error queue prior 
to any of the three SSL_* calls that mod_ssl makes. An ideal fix might 
be to keep the error queue empty at all times (i.e. patch the APR crypto 
library), but I propose that this patch is more robust in a modular 
environment.


Thanks for your consideration.

[1] 
https://www.openssl.org/docs/manmaster/ssl/SSL_get_error.html#DESCRIPTION

[2] https://bz.apache.org/bugzilla/show_bug.cgi?id=60223

Regards,
Paul Spangler
LabVIEW R
National Instruments

Re: svn commit: r1764961 - in /httpd/httpd/trunk: docs/manual/mod/core.xml modules/http/http_filters.c server/core.c server/gen_test_char.c server/protocol.c server/util.c

2016-10-17 Thread William A Rowe Jr 
On Mon, Oct 17, 2016 at 1:48 PM, Roy T. Fielding  wrote:

> On Oct 15, 2016, at 2:10 AM, William A Rowe Jr 
> wrote:
>
> On Sat, Oct 15, 2016 at 3:54 AM, William A Rowe Jr 
> wrote:
>
>> On Fri, Oct 14, 2016 at 4:44 PM, Roy T. Fielding 
>> wrote:
>>
>>> Right, though several people have requested it now as errata. Seems
>>> likely to be in the final update for STD.
>>>
>>
>> In the HttpProtocolOptions Unsafe mode, it is tolerated.
>>
>> Should it be the proper 'Strict' behavior to parse (never generate) such
>> noise?
>>
>
> FWIW, I see very little harm in potentially unsafe chunk headers because
> it becomes a serious chore to inject between alternating \r-only vs
> \n-only
> vs space trailing chunk headers. I'm not suggesting it can't be done, but
> most requests-with-body are intrinsically not idempotent, so one must be
> extremely clever to affect cache history.
>
> But it isn't impossible, so if the editors follow the way of BWS vs.
> follow
> the absolute explicit statements about HTTP request field names and
> the trailing ':', I'd be somewhat disappointed. Tighten ambiguity where
> there was little ambiguity before. Make explicit the real ambiguity for
> all user-agents and servers to implement. /shrug.
>
>
> We tried.  People complained.
>
> In any case, BWS only includes *( SP / HTAB ).  Not much ambiguity there.
>

Fair enough. There is no BWS allowed at present, nor a bare CR or LF, at
this
point. httpd is free to respond with any action it likes.

The original and distributed behaviors allow CRLF or LF, CR followed by
other
than LF was disallowed. The new trunk behavior disallows a bare LF also.

The original action was *(SP / HTAB), the distributed behavior restricts
this
to 10 SP/HTAB characters, the new trunk behavior disallows SP / HTAB
between the final hex digit and ';' delimiter. Note that we don't support
the
true *(SP / HTAB) rule by limiting it very severely.

I favor leaving the new no-space-tolerance rule but will accept the group's
choices, Roy appears to concede to accepting some BWS. I guess a quick
poll is in order... opinions?

Re: svn commit: r1764961 - in /httpd/httpd/trunk: docs/manual/mod/core.xml modules/http/http_filters.c server/core.c server/gen_test_char.c server/protocol.c server/util.c

2016-10-17 Thread Roy T. Fielding 
> On Oct 15, 2016, at 2:10 AM, William A Rowe Jr  wrote:
> 
> On Sat, Oct 15, 2016 at 3:54 AM, William A Rowe Jr  > wrote:
> On Fri, Oct 14, 2016 at 4:44 PM, Roy T. Fielding  > wrote:
> Right, though several people have requested it now as errata. Seems likely to 
> be in the final update for STD.
> 
> In the HttpProtocolOptions Unsafe mode, it is tolerated.
> 
> Should it be the proper 'Strict' behavior to parse (never generate) such 
> noise? 
> 
> FWIW, I see very little harm in potentially unsafe chunk headers because
> it becomes a serious chore to inject between alternating \r-only vs \n-only 
> vs space trailing chunk headers. I'm not suggesting it can't be done, but
> most requests-with-body are intrinsically not idempotent, so one must be
> extremely clever to affect cache history. 
> 
> But it isn't impossible, so if the editors follow the way of BWS vs. follow 
> the absolute explicit statements about HTTP request field names and
> the trailing ':', I'd be somewhat disappointed. Tighten ambiguity where
> there was little ambiguity before. Make explicit the real ambiguity for
> all user-agents and servers to implement. /shrug.

We tried.  People complained.

In any case, BWS only includes *( SP / HTAB ).  Not much ambiguity there.

Roy