gmane.comp.apache.devel

Re: svn commit: r1482522 - in /httpd/httpd/trunk: ./ docs/log-message-tags/ include/ modules/dav/main/ modules/generators/ modules/http/ modules/proxy/ server/

Yann Ylavic — 2013-05-19T13:29:51

Here are the 3 patches attached as files (without spurious line breakage).

Regards,
Yann.


On Fri, May 17, 2013 at 7:27 PM, Yann Ylavic <ylavic.dev< at >gmail.com> wrote:

Bug report for Apache httpd-2 [2013/05/19]

2013-05-19T07:15:06

+---------------------------------------------------------------------------+
| Bugzilla Bug ID                                                           |
|     +---------------------------------------------------------------------+
|     | Status: UNC=Unconfirmed NEW=New         ASS=Assigned                |
|     |         OPN=Reopened    VER=Verified    (Skipped Closed/Resolved)   |
|     |   +-----------------------------------------------------------------+
|     |   | Severity: BLK=Blocker CRI=Critical  REG=Regression  MAJ=Major   |
|     |   |           MIN=Minor   NOR=Normal    ENH=Enhancement TRV=Trivial |
|     |   |   +-------------------------------------------------------------+
|     |   |   | Date Posted                                                 |
|     |   |   |          +--------------------------------------------------+
|     |   |   |          | Description                                      |
|     |   |   |          |                                                  |
| 7483|As

Re: Intent to revert commit r1332643

Jim Jagielski — 2013-05-18T03:26:48

Please don't submit what could be controversial reverts
over a weekend.

On May 17, 2013, at 10:36 AM, Guenter Knauf <fuankg< at >apache.org> wrote:

Re: svn commit: r1482522 - in /httpd/httpd/trunk: ./ docs/log-message-tags/ include/ modules/dav/main/ modules/generators/ modules/http/ modules/proxy/ server/

Yann Ylavic — 2013-05-17T17:27:07

I am currently working in frontporting some patches I use for a while
in the 2.2.x branch and I'd like to propose for trunk (at least, my
goal is to upgrade to 2.4 of course).

The reason I talk about this in this thread is that 2 of these patches
may collide with your current work/review on ap_http_filter() and
maybe it worth taking my suggestions into account. If I should open a
different thread let me know...

My 2 patches serve the following purposes :
1. make mod_proxy_http handle a truncated response body (closed
connection with remaining data) like any other streaming error,
2. make LimitRequestBody also apply to mod_proxy_http forwarded requests,
3. make mod_proxy_http respond the HTTP error mapping the
ap_http_filter() status.

1. When ap_http_filter() returns APR_EOF, currently mod_proxy simply
stops forwarding the response, no log, no error bucket, like a normal
end of sream.
For an output filter there is no way to be aware of the problem, and
mod_cache (for example) will cache an incomplete entit

Intent to revert commit r1332643

Guenter Knauf — 2013-05-17T14:36:12

Hi all,
I will revert the changes done with:
http://svn.apache.org/viewvc?view=revision&revision=1332643
after 72 hours if nobody is going to fix the stuff properly for Windows 
since I'm tired of always copying mod_ssl over from 2.4.x branch in 
order to get a working mod_ssl with trunk.

Reasons:
1) within last 12 months there was no attempt made to fix the issues 
which wrowe mentioned in this thread [1] - instead discussion died
2) a suggestion to fix the issue [2] was not applied due to the concerns 
wrowe brought up, and to which I agree.
3) the same issue also causes a stalled backport in 2.2.x STATUS [3] for 
the last 12 months

[1] 
http://mail-archives.apache.org/mod_mbox/httpd-dev/201302.mbox/%3C20130205115224.33547872< at >hub%3E
[2] 
http://mail-archives.apache.org/mod_mbox/httpd-dev/201302.mbox/%3C510D8293.8010103< at >gknw.net%3E
[3] http://svn.apache.org/viewvc?view=revision&revision=1333501

I believe that one year in trunk without further review is long enough, 
and if someone wants to continue worki

Re: svn commit: r1480058 - in /httpd/httpd/trunk: CHANGES modules/proxy/mod_proxy_ftp.c modules/proxy/mod_proxy_http.c modules/proxy/proxy_util.c

Yann Ylavic — 2013-05-17T12:15:08

Sorry to interfere in the debate with a non-RFC argument but there may be
aftermath by changing a long standing mod_proxy 502 error for almost any
non-recoverable problem with the upstream server.

On Wed, May 8, 2013 at 10:06 AM, Graham Leggett <minfrin< at >sharp.fm> wrote:

Some (third-party-)modules/filters/scripts that rely on the 502 error
(bucket) to take an action regarding the upstream server will also be
confused by the commit.

For example ap_http_outerror_filter(), ap_http_chunk_filter() and maybe
others (grep where HTTP_BAD_GATEWAY is checked in the source tree) should
be modified accordingly.

I guess this argument may not be weighty relative to RFC compliance...

 On Wed, May 8, 2013 at 9:47 AM, Ruediger Pluem <rpluem< at >apache.org> wrote:


Do you mean 504, like 503, is admissible for idempotent requests replay or
balancer failover ?
Currently this is not the case...

Regards,
Yann.

Re: svn commit: r1482522 - in /httpd/httpd/trunk: ./ docs/log-message-tags/ include/ modules/dav/main/ modules/generators/ modules/http/ modules/proxy/ server/

Graham Leggett — 2013-05-17T10:03:57


I tried to get my head around the ap_http_filter, it contains way too many 'if special case do special stuff' statements, particularly around the sending of eos buckets, I suspect one of those might be tripping it up.

It looks like some simplifying could eliminate an apr_brigade_flatten and another 40-ish bytes per request, will take a look.

Regards,
Graham
--

Re: svn commit: r1482522 - in /httpd/httpd/trunk: ./ docs/log-message-tags/ include/ modules/dav/main/ modules/generators/ modules/http/ modules/proxy/ server/

Ruediger Pluem — 2013-05-17T09:26:56


Graham Leggett wrote:

We should not see an EOS bucket before

inflate(&ctx->stream, Z_NO_FLUSH); in line 1061 returned Z_STREAM_END. This would mean we received an incomplete
compressed stream.
And if we see Z_STREAM_END we leave the for loop and stop processing buckets. Hence we cannot hit a possible EOS bucket
in the brigade any longer.
So the test possibly sents an incomplete compressed body.


Regards

Rüdiger

Requesting feedback - RFC5878

Scott Deboy — 2013-05-16T22:45:15

I'm re-implementing support for RFC5878 (TLS authorization extensions) in OpenSSL and subsequently mod_ssl.

I am working on contributing back the OpenSSL changes and would like to contribute back the mod_ssl changes.

A little RFC5878 background: Client sends a TLS extension representing the auth format(s) it supports.  If the server supports the auth format(s), it sends back the same TLS extension.  If either side needs to send data, the data is sent in the supplemental data message.  Apps may choose to do this only during renegotiation.

I have working versions of OpenSSL and mod_ssl which exercise RFC5878 with DTCP-based authorization - a new RFC is in-progress to support DTCP-based authorization in RFC5878.  The current only implements support for DTCP-based authorization - it doesn't provide support for the AuthzDataFormats defined in RFC5878.  Hhowever, the OpenSSL API doesn't change, and implementing mod_ssl support for the other AuthzDataFormats should be straightforward.

DTCP-based authorization r

Re: svn commit: r1482522 - in /httpd/httpd/trunk: ./ docs/log-message-tags/ include/ modules/dav/main/ modules/generators/ modules/http/ modules/proxy/ server/

Graham Leggett — 2013-05-16T15:35:02


Looking at a verbose version of this test, we see this:

# expected: begin-foobar-end
# received: <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
# <html><head>
# <title>400 Bad Request</title>
# </head><body>
# <h1>Bad Request</h1>
# <p>Your browser sent a request that this server could not understand.<br />
# </p>
# </body></html>
not ok 4

Tracing through the code, we get a bad request because we trip over this code in mod_deflate:

            /* If we actually see the EOS, that means we screwed up! */
            if (APR_BUCKET_IS_EOS(bkt)) {
                inflateEnd(&ctx->stream);
                ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r, APLOGNO(01390)
                              "Encountered EOS bucket in inflate filter (bug?)");
                return APR_EGENERAL;
            }

Why does seeing an EOS in the input stream mean we screwed up? I don't follow.

Regards,
Graham
--

Re: help with fixing a mod_auth_form bug regarding kept_body

David Mansfield — 2013-05-16T14:45:23

On 05/16/2013 09:32 AM, Graham Leggett wrote:

Thanks for your help.

First of all, the bug report was not put in by me, just found by me.  I 
have done extensive debugging in the source code to determine some basic 
facts, primarily that, when using an ErrorDocument it is impossible to 
"keep" the POST body using the kept_body_filter.  The r->kept_body is 
simply not assigned to the sub request in "internal_internal_redirect" 
(and even after "fixing" this and recompiling, it doesn't work because 
the filter "ctx" variable is not preserved).

I was asking the question "has anyone ever seen this working", because 
it seems that there is no possible way it could ever work AFACT.

However, if it means someone may help, here is a simple test case:

To start with, the goal is a user should be able to POST data from 
within (say) an expired session or unprotected part of the website when 
not-yet-logged-in, get the login page, enter credentials, and the 
originally POSTed data should be POSTed to the original ta

Re: help with fixing a mod_auth_form bug regarding kept_body

Graham Leggett — 2013-05-16T13:32:06


As applies to everyone who posts to a public mailing list asking for help, we need a proper description of the problem, including an example config that would allow someone else to reproduce the problem you are seeing.

The bugreport contains a single paragraph with a vague description of the problem, and this tells us nothing. Was the server set up correctly? No way to tell.

Regards,
Graham
--

Re: help with fixing a mod_auth_form bug regarding kept_body

Eric Covener — 2013-05-16T13:26:37

This is the right place, despite the fact that nobody has shown
interest in your issue in this thread.

Re: help with fixing a mod_auth_form bug regarding kept_body

David Mansfield — 2013-05-16T12:48:12

On 05/08/2013 10:34 AM, David Mansfield wrote:

Wow for a "dev" list there is nobody who can even comment in any way 
whatsoever.  Where do the devs for httpd live for real?  IRC? Anyone? 
Bueller?

Re: proxy segfault in httpd-trunk

Jim Jagielski — 2013-05-16T12:28:36

On May 16, 2013, at 4:19 AM, Thomas Eckert <thomas.r.w.eckert< at >gmail.com> wrote:


Hold on a tic... the server-conf is created for each server and
it's a *module* level action. It happens whether the top-level
server uses a proxy-or-not. That is, create_server_config
is done on each and every server, regardless of whether
that server *uses* mod_proxy at all. So base->pool and base->mutex
will always line up with a created subpool and mutex since
base is *guaranteed* to exist and base-><field> is guaranteed
to have been created (if done so in create_server_config).

Even with all that, I like Graham's mutex impl better and
with http://svn.apache.org/r1483190 we now ensure child processes
have access to it (which is likely what the orig issue really
was)

Re: proxy segfault in httpd-trunk

Thomas Eckert — 2013-05-16T08:19:14

Looks like it. At least I don't see a reason why Nick's reasoning would
apply to the mutex but not to the pool.


I must admit I'm not familiar enough with the httpd modules at large to be
an expert here but to me it *feels* weird to put such a central piece of
module management outside the module's config structure. It would solve the
problem with create_config/merge_config though and it's also a bit better
performance wise (see Graham's commit). Hm, maybe it doesn't feel so weird
after all ...



I thought about this as well but decided against it because I figured
creating those sub pools would be a much larger performance hit then just
having a locking mechanism in place. It'd be a different matter with sub
pools being pre-allocated, 'swapped' into place when needed, etc. This
feels like going way overboard though.


On Thu, May 16, 2013 at 5:20 AM, Jim Jagielski <jim< at >jagunet.com> wrote:

Re: proxy segfault in httpd-trunk

Jim Jagielski — 2013-05-16T03:20:50

Hmmm... The other idea is to keep it as it was,
stick pconf back in conf->pool but just always create
a sub-pool before conf->pool is used. This *looks*
like it removes the need for a mutex...

On May 15, 2013, at 7:37 PM, Jim Jagielski <jim< at >jaguNET.com> wrote:

Re: proxy segfault in httpd-trunk

Jim Jagielski — 2013-05-15T23:37:12

Just wondering if we also have a problem with the pool
as well... if base doesn't have a proxy, we don't have
the subpool.

BTW, wondering if instead of leaking proxy_mutex we
could set ps->mutex = proxy_mutex in mod_proxy.c when
we merge. We could then make proxy_mutex static...?

On May 15, 2013, at 7:27 PM, Graham Leggett <minfrin< at >sharp.fm> wrote:

Re: proxy segfault in httpd-trunk

Graham Leggett — 2013-05-15T23:27:49


Here is one I made earlier: http://svn.apache.org/r1482859

Regards,
Graham
--

Re: proxy segfault in httpd-trunk

Jim Jagielski — 2013-05-15T23:25:30

Ugg. You're 100% right. We need to create a global.

On May 14, 2013, at 3:35 PM, Nick Kew <nick< at >webthing.com> wrote:

Re: svn commit: r1482522 - in /httpd/httpd/trunk: ./ docs/log-message-tags/ include/ modules/dav/main/ modules/generators/ modules/http/ modules/proxy/ server/

Graham Leggett — 2013-05-15T19:39:29


I get this:

t/apache/pr17629.t .. 
1..0 # skipped: cannot find module 'case_filter'
skipped: cannot find module 'case_filter'
Files=1, Tests=0,  1 wallclock secs ( 0.03 usr  0.01 sys +  0.63 cusr  0.33 csys =  1.00 CPU)
Result: NOTESTS

Let me figure out why the case_filter is missed and try this again.

Regards,
Graham
--