Ruediger Pluem wrote:
+AP_DECLARE(int) ap_unescape_all(char *url);
+
+/**
Doesn't this require a minor bump?
I think it does do, yes. Fixed.
+AP_DECLARE(char *) ap_escape_path_segment_b(char *c, const char *s);
This is not a very descriptive name. Shouldn't it be better
ap_escape_path_s
Ruediger Pluem wrote:
+res = apr_evp_factory_create(f, conf->keyfile,
conf->certfile, NULL,
+ NULL, NULL, conf->digest, APR_EVP_FACTORY_ASYM,
r->pool);
How do you know that a conf->keyfile was set?
You don't need to know, either option is valid - your options are t
Ruediger Pluem wrote:
+/* load anonymous sessions */
+if (conf->name_set || conf->name2_set) {
+
+/* load RFC2109 compliant cookie */
+if (conf->name_set) {
+ap_cookie_read(r, conf->name, &key, conf->remove);
+}
+
+/* load RFC2965 compliant coo
Chris Darroch wrote:
Great idea. What would you think about converting from
the session_save hook to a provider-based mechanism? I can
imagine that administrators might want/need to use one kind of
storage provider (dbd, say) for sessions on high-priority virtual hosts,
while using another l
William A. Rowe, Jr. wrote:
Hmmm... why can't I use a session across an entire vhost?
As in RSRC_CONF|ACCESS_CONF?
Regards,
Graham
--
smime.p7s
Description: S/MIME Cryptographic Signature
Ruediger Pluem wrote:
Should IMHO result in the usage of somecipher for requests below /blah.
With the current code this is IMHO not the case as the default value
AES256-SHA
will be used for requests below /blah while somecipher is used for requests
below /blub.
I looked at this a number of
Chris Darroch wrote:
You have to register statements to be prepared prior to the
post_config phase ... that's the main one I can think of. Does
that help?
Is that prior to or up to? If it's up to, it would help me a lot...
Regards,
Graham
--
smime.p7s
Description: S/MIME Cryptographic Si
Joe Orton wrote:
mod_session_cookie.c:59: warning: no previous prototype for
'ap_session_cookie_save'
I just checked for any unchecked in files, and found a change to
Makefile.in that hadn't been checked in. Can you try and svn update and
confirm whether it fixes it?
Regards,
Graham
--
[EMAIL PROTECTED] wrote:
URL: http://svn.apache.org/viewvc?rev=645877&view=rev
Log:
No var declarations in the middle of the code.
This looked suspiciously like a change of line endings happened somehow?
Regards,
Graham
--
smime.p7s
Description: S/MIME Cryptographic Signature
Joe Orton wrote:
I think it's appropriate that the "smallness" is brought out:
1) the fact that some providers (shmcb, memcache at least) have fixed
size limits means any consumer must be designed to cope with that,
2) for a cache which could store arbitrarily large objects, you'd want a
di
[EMAIL PROTECTED] wrote:
Session cache interface redesign, Part 8:
Is this stuff documented yet? (Or am I jumping the gun...?)
Regards,
Graham
--
smime.p7s
Description: S/MIME Cryptographic Signature
Guenter Knauf wrote:
maybe you can already commit mod_auth_form for the un-patient even though
docu might not be ready yet? I've just now a little bit time to look into
building the whole session stuff properly on NetWare...
I just did :)
Regards,
Graham
--
smime.p7s
Description: S/MIME Cry
Takashi Sato wrote:
Please use svn:keywords = LastChangedRevision .
Done.
Regards,
Graham
--
smime.p7s
Description: S/MIME Cryptographic Signature
Roy T. Fielding wrote:
-1. Bloat like this belongs in a module.
This piece of code depends on the KeptBodySize directive, which is part
of the http_filter, and sits alongside ap_discard_request_body().
I can move it into another module, but then that just gives the
administrator one extra
Joe Orton wrote:
I don't understand why *that* stuff needed to be in the core. It is
certainly possible to consume then reinject the request body, without
changing one line of core filters; it's done in mod_ssl, see
ssl_io_filter_buffer/ssl_io_buffer_fill.
What about modules that call ap_di
Joe Orton wrote:
The entire request body passes through the input filter stack when it is
being discarded. So an input filter inserted by a module can capture
and buffer it somewhere very easily; and can provide access to that
buffered copy however it likes, without needing to modify request_
[EMAIL PROTECTED] wrote:
URL: http://svn.apache.org/viewvc?rev=646445&view=rev
Log:
Let each consumer of authn providers redefine the list_provider_names
callback in case they are loaded individually without mod_authn_core.
Modified:
httpd/httpd/trunk/modules/aaa/mod_auth_basic.c
httpd/
Chris Darroch wrote:
Can you check if mod_auth_form also needs this?
Yes, it does -- looks like you're doing your own ap_lookup_provider()
calls on the authn provider group.
This was based originally on the mod_auth_basic code. I didn't want to
make a change that I didn't fully understand
Roy T. Fielding wrote:
New features belong in modules so that they don't get compiled into
the server by those of us who don't want that feature. I don't recall
why or how KeptBodySize made it into http_filter (where it does not
belong),
but I am quite certain that the core will not be parsin
Nick Kew wrote:
c.f. my mod_form (at apache.webthing.com), which does just that,
providing optional functions for other modules to access the
form data.
This is upside down - modules should not have to do anything at all to
get a possibly inserted request body or form data. What happens when
Akins, Brian wrote:
This kind of stuff belongs in a
common place.
Doesn't libapreq do this??
Do what exactly?
Regards,
Graham
--
smime.p7s
Description: S/MIME Cryptographic Signature
Jeff Trawick wrote:
I need this to build trunk:
Why nobody else?
Could it be because you've included mod_auth_form, but not included
mod_session?
mod_session may need to export itself using optional functions, will
take a look.
Regards,
Graham
--
smime.p7s
Description: S/MIME Crypto
Roy T. Fielding wrote:
New features belong in modules so that they don't get compiled into
the server by those of us who don't want that feature. I don't recall
why or how KeptBodySize made it into http_filter (where it does not
belong),
but I am quite certain that the core will not be parsin
Guenter Knauf wrote:
in order to simplify future configuration, and most important to have same
include path structure with both in-tree and installed compilations I think it
makes sense to move all mod_*.h headers with public APIs to the common
./include folder.
Current votes:
+1 wrowe, fu
Rüdiger Plüm wrote:
Its seems that the recent commits from Graham (r647263) and Mladen
(r647384) (APR) broke httpd trunk:
server/.libs/libmain.a(exports.o):(.data+0x588): undefined reference to
`ap_keep_body_filter'
server/.libs/libmain.a(exports.o):(.data+0x58c): undefined reference to
`ap_
Hi all,
I am trying to get a core dump out of an RHEL5 system, and I am
struggling to do so.
Following the instructions at
http://httpd.apache.org/dev/debugging.html#crashes, I have set "ulimit
-c unlimited", and I set CoreDumpDirectory to /tmp, but with no luck.
Is there some further magi
Ahab Abouzour wrote:
IIS6 has a very useful feature called "application pools", where you can
> dedicate resources/worker processes per "application".
Apache, until today, does not have such feature. Is there any plans to
> implement this feature in future Apache releases.
The easiest way t
Ruediger Pluem wrote:
++//if (APR_SUCCESS ==
apr_password_validate(apr_pstrcat(r->pool, sent_user, ":", site, NULL),
+// sent_hash)) {
This is a C++ style comment that breaks with ANSI compilers.
I think it would be better to rem
Res wrote:
So what would be the impact to having a very large httpd.conf file,
having to read in, perhaps many thousands of extra directory blocks?
If only 100 or 1000 want it thats fine, but if i end up with 10+K
wanting it, I would like to know what impact I may expect, what would be
the memo
Ruediger Pluem wrote:
+/* all is well, set aside the buckets */
+for (bucket = APR_BRIGADE_FIRST(b);
+ bucket != APR_BRIGADE_SENTINEL(b);
+ bucket = APR_BUCKET_NEXT(bucket))
+{
+apr_bucket_copy(bucket, &e);
What about transient buckets? Don't we need to set
Plüm wrote:
What about transient buckets? Don't we need to set them aside?
I don't follow - does the apr_bucket_copy not do that for us already?
No, it does not.
Let me look further.
In theory, that would mean you could only read the kept_body
once. The
kept body could be delivered to mu
Hi all,
While debugging something else entirely I have tripped over an abort()
triggered from inside mod_dir when POOL_DEBUG is enabled.
It seems within ap_internal_fast_redirect(), an attempt is made to do this:
r->notes = apr_table_overlay(r->pool, rr->notes, r->notes);
The abort occur
Dirk-Willem van Gulik wrote:
There is a lot of valuable stuff in your jumbo patch - but I am not sure
what the best approach is to fold it in.
Could you have have a look at the rough patch I posted earlier today -
and let me know if you have any thoughts
as to which parts should be moved 'up'
Ruediger Pluem wrote:
Why is this needed? Should this job be performed by the
ap_keep_body_filter that should
be in our input filter chain if we want to keep the body?
Of course this depends when we call ap_parse_request_form. If we call it
during the
authn/z phase the filter chain hasn't been
Niklas Edmundsson wrote:
I'm not convinced that forking the disk cache having two similar ones
tuned for different usecases is a good idea in the long run, I'm pretty
sure that the parts that needs tweaking can be solved with config
options and documentation. For a development sprint like this
Roy T. Fielding wrote:
Please tell me that the chunk above is a mistaken commit.
The chunk above is a mistaken commit.
Regards,
Graham
--
smime.p7s
Description: S/MIME Cryptographic Signature
William A. Rowe, Jr. wrote:
I think the bigger idea that mod_cache must handle all rfc related issues
is key. mem and disk cache should never have had substantial differences
in behavior, but they do.
So the more we can consolidate in mod_cache w.r.t. the requests themselves,
the less the back
Ruediger Pluem wrote:
+if (sent_body && sent_mimetype) {
+apr_table_set(r->headers_in, "Content-Type", sent_mimetype);
+r->kept_body = sent_body;
Any reason why we do not need to adjust the Content-Length header any
longer?
That's done inside the init functio
Brad Nicholes wrote:
Trying to build mod_auth_form.c just produces link errors. I can see where
> the optional function is imported as ap_session_set_fn() but then later
> referenced as ap_session_set(). The code should be changed to use one or
> the other right?
I just fixed this in r655205
Ruediger Pluem wrote:
As I would not like to see 2.2.9 already *dependent* on apr / apr-util
1.3.x
(only shipped with apr / apr-util 1.3.x) I propose to do this only on trunk
and postpone backporting to the point of time where we make 2.2.x dependent
on 1.3.x which IMHO depends on the real live
William A. Rowe, Jr. wrote:
Nothing, as pointed out before the || escapes any --avoid-ldap failure.
I wasn't pushing, because I hadn't had a chance to try a no-so's, static
build, but things look good here. --ldap-libs are added for our monolithic
httpd binary from the module's LDADD path, fro
Thomas Lee wrote:
I'd love to contribute some code to the Apache web server, but it's a
little intimidating to know quite where to start. Obviously the bug
tracker was my first port of call, but it's difficult to determine which
defects would be good for a new developer to look at.
Even if n
Müller Johannes wrote:
we want to use client authorization against LDAP using client certificates on
Apache webserver 2.2.
Unfortunately this is not possible with Apache webserver at the current state
of development.
There have been third party modules (ModXAuthLDAP, mod_authz_ldap) in the pas
Müller Johannes wrote:
So far so good, but how to handle fallback to basic authentication if the
client has no certificate (SSLVerifyClient optional)?
If we created a new module mod_auth_cert and there is no username from mod_ssl
we would like to call mod_auth_basic.
If i understood you right,
Müller Johannes wrote:
Maybe let's concentrate on non-third-party modules.
Basically there is mod_auth_basic and mod_auth_digest on the top level followed
by their providers on the second level.
mod_auth_form is part of httpd trunk, and is not a third party module.
Regards,
Graham
--
smim
On 06 Feb 2013, at 12:22 PM, p...@talk21.com wrote:
> How many Linux distros ship httpd 2.4?
>
> Fedora 18 is their first release to include httpd 2.4. Since Fedora is often
> an early adopter of new releases, I expect 2.4 hasn't trickled down to other
> distributions yet, e.g. RHEL, CentOS.
>
On 09 Feb 2013, at 10:05 AM, Christophe JAILLET
wrote:
> Anyway, just my 2 cents:
>
>- providing packages, as already discussed in the list
> ==> would ease distro update or end user installation
We already provide packages for RPM based distributions, and have documented it
too: http://h
On 12 Feb 2013, at 5:31 PM, Thomas wrote:
> Looking at mod_firehose from trunk, is there any effort going on or already
> concluded on converting the output of mod_firehose or it's parser program
> firehose to the pcap format ? I know it was shortly discussed during the
> mod_firehose integret
On 19 Feb 2013, at 10:12 AM, Michael Felt wrote:
> Packaging went well, but still several compiler syntax warnings. Also, a
> configure warning - that I hope has no influence:
> configure: WARNING: Your APR does not include SSL/EVP support. To enable it:
> configure --with-crypto
> as I have --
On 19 Feb 2013, at 1:57 PM, Michael Felt wrote:
> so, it is intended that mod_crypto is not included with
> --enable-mods-shared=all (and/or --enable-mpms-shared=all)?
There is no such module as mod_crypto, rather a module called
mod_session_crypto. This module uses simple symmetrical encrypti
On 24 Feb 2013, at 4:31 PM, Eric Covener wrote:
> probably CHANGES-worthy
And backport worthy, existing behaviour looks broken to me.
Regards,
Graham
--
smime.p7s
Description: S/MIME cryptographic signature
On 18 Feb 2013, at 10:34 PM, Jim Jagielski wrote:
> The pre-release test tarballs for Apache httpd 2.4.4 can be found
> at the usual place:
>
> http://httpd.apache.org/dev/dist/
>
> I'm calling a VOTE on releasing these as Apache httpd 2.4.4 GA.
> NOTE: The -deps tarballs are included her
On 26 Feb 2013, at 7:52 AM, Christophe JAILLET
wrote:
> in the old PR51699, Stefan Fritsch turned a sequence like:
> APR_BRIGADE_INSERT_TAIL(bb, apr_bucket_pool_create(...));
> into:
> apr_brigade_putstrs(bb, NULL,...);
>
> (http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/filters
On 06 Mar 2013, at 12:04 PM, Yann Ylavic wrote:
>> I've been working on a patch for mod_cache to deal (fully) with the
>> response header Cache-Control and the no-cache= or private=
>> directives.
>
> I realize that, maybe, the patch should have been included in the
> message, rather than in an
On 04 Mar 2013, at 8:22 PM, ylavic dev wrote:
> I've been working on a patch for mod_cache to deal (fully) with the response
> header Cache-Control and the no-cache= or private= directives.
> This "feature" is mainly used with the Set-Cookie header, and allows the
> origin server to control the
On 11 Mar 2013, at 11:39 AM, wrote:
> I’ve got a server configured in ReverseProxy Mode, that forward requests
> towards several backends named with their proper names.
>
> It appears that the DNS Lookup is done for each requests, generating a very
> load traffic on my DNS servers…
>
> Is t
On 11 Mar 2013, at 12:50 PM, Yann Ylavic wrote:
>> The way I read the spec, "the specified field-name(s) MUST NOT be sent in
>> the response to a subsequent request without successful revalidation with
>> the origin server". What this means is that if the specified field names are
>> found to
On 13 Mar 2013, at 7:27 PM, Yann Ylavic wrote:
> How would the origin invalidate a Set-Cookie, with an empty one ?
I would imagine with a 200 OK.
Roy would be able to confirm.
Regards,
Graham
--
smime.p7s
Description: S/MIME cryptographic signature
On 17 Mar 2013, at 6:54 PM, Eric Covener wrote:
> If we maintain the use of a password here, like mod_ssl does, wouldn't
> we need to make sure it doesn't come in over the wire?
We use apr_table_setn() which replaces anything that is there already, although
if either the username or the passwor
On 18 Mar 2013, at 11:13 PM, s...@apache.org wrote:
> Author: sf
> Date: Mon Mar 18 21:13:31 2013
> New Revision: 1458003
>
> URL: http://svn.apache.org/r1458003
> Log:
> simplify code by using ap_bin2hex()
> -for (idx = 0; idx < APR_SHA1_DIGESTSIZE; idx++) {
> -*hash++ = hex[sha1[id
On 19 Mar 2013, at 7:09 PM, Jim Jagielski wrote:
> I've added bypassing and removing... for flexibility.
Is there a generic way for modules to figure out for themselves whether they
should be caring about a particular request or connection?
In other words, if reqtimeout had a way to say "is th
On 19 Mar 2013, at 7:44 PM, Jim Jagielski wrote:
> Agreed... The conn_rec includes a bunch of HTTP related fields
> which could serve as such, but the main issue, I think, is
> that websockets starts off as HTTP and then changes, so the
> initial conn_rec info is HTTP, it's just that after the
>
On 22 Mar 2013, at 10:54 PM, Stefan Fritsch wrote:
> On Tuesday 19 March 2013, Jim Jagielski wrote:
>> This would be EXTREMELY easy just using ->notes
>
> But having to do a hash lookup in ->notes on every read from the
> network seems rather inefficient to me. I think an optional function
> o
On 27 Mar 2013, at 6:06 PM, Yann Ylavic wrote:
> Index: modules/cache/mod_cache.h
> ===
> --- modules/cache/mod_cache.h (revision 1461557)
> +++ modules/cache/mod_cache.h (working copy)
> @@ -152,9 +152,12 @@
>
> /* Create a new tab
On 03 Apr 2013, at 3:20 AM, Wim Lewis wrote:
> The patches in 50773, 53525, 53910, 54610, and 54611 perhaps should be
> evaluated by someone with more familiarity with the server internals before
> they are committed, but I'd be especially grateful if someone would look at
> 53910, 54610, and/
Hi all,
Currently mod_ssl doesn't work with the event MPM, as per the following code:
if (c->clogging_input_filters && !c->aborted) {
/* Since we have an input filter which 'cloggs' the input stream,
* like mod_ssl, lets just do the normal read from input filters,
*
On 19 Apr 2013, at 6:38 PM, Eric Covener wrote:
>> What would it take to make mod_ssl a non-clogging filter?
>
> Basically needs two things:
> 1) Never buffer data inside ssl (feasible I believe)
> 2) Create a new way for a filter deep inside the chain to indicate we
> need to wait for a read/wr
On 23 Apr 2013, at 4:27 AM, William Lewis wrote:
> I've tested the patches in 53910, 54610, and 54611 against trunk as well as
> 2.4.4; they apply and they fix their respective bugs (at least as far as my
> test cases go). I don't have an easy way to test 53525, though.
I've committed these to
Hi all,
A number of the modules have flags, and with additions typically over time the
flags end up looking like this, which takes up a lot of space:
struct {
[variable]
[flag]
[variable]
[flag]
…
}
Would it make sense to group the flags at the beginning,
On 30 Apr 2013, at 12:03 PM, André Warnier wrote:
> The only cost would a relatively small change to the Apache webservers, which
> is what my
> suggestion consists of : adding a variable delay (say between 100 ms and 2000
> ms) to any
> 404 response.
This would have no real effect.
Bots are
On 30 Apr 2013, at 4:23 PM, j...@apache.org wrote:
> Modified:
>httpd/httpd/branches/2.4.x/ (props changed)
>httpd/httpd/branches/2.4.x/Apache-apr2.dsw
>httpd/httpd/branches/2.4.x/Apache.dsw
>httpd/httpd/branches/2.4.x/CHANGES
>httpd/httpd/branches/2.4.x/Makefile.win
>htt
On 30 Apr 2013, at 8:42 PM, Ben Laurie wrote:
>> This would have no real effect.
>>
>> Bots are patient, slowing them down isn't going to inconvenience a bot in
>> any way. The simple workaround if the bot does take too long is to simply
>> send the requests in parallel.
>
> Disagree. Raising
On 01 May 2013, at 2:47 AM, André Warnier wrote:
> With respect, I think that you misunderstood the purpose of the proposal.
> It is not a protection mechanism for any server in particular.
> And installing the delay on one server is not going to achieve much.
>
> It is something that, if it is
On 01 May 2013, at 11:34 AM, Marian Marinov wrote:
> Actually, what we are observing is completely opposite to what you are saying.
> Delaying spam bots, brute force attacks, and vulnerability scanners
> significantly decreases the amount of requests we get from them.
> So, our observation tells
On 01 May 2013, at 1:14 PM, Ben Laurie wrote:
> The fact you cannot explain the evidence does not invalidate the evidence.
The evidence was just explained - a bot that does not get an answer quick
enough gives up and looks elsewhere.
The key words are "looks elsewhere".
> Jeez.
While some p
On 01 May 2013, at 1:51 PM, André Warnier wrote:
> But *based on the actual data and patterns which I can observe on my servers
> (not guesses), I think it might have an effect*.
Of course it might have an effect - the real important question is will it have
a *useful* effect.
A bot that give
On 03 May 2013, at 11:54 AM, André Warnier wrote:
> So here is a challenge for the Apache devs : describe how a bot-writer could
> update his software to avoid the consequences of the scheme that I am
> advocating, without consequences on the effectivity of their URL-scanning.
Attempt to proce
On 05 May 2013, at 4:34 PM, Ruediger Pluem wrote:
>> Modified: httpd/httpd/trunk/modules/cache/cache_util.c
>> URL:
>> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/cache/cache_util.c?rev=1479222&r1=1479221&r2=1479222&view=diff
>>
On 08 May 2013, at 9:47 AM, Ruediger Pluem wrote:
> I don't agree with this. The case you mention is only true if the client
> sends Cache-Control: must-revalidate.
> If this is not the case IMHO 10.5.3 and 10.5.5 apply.
> And only a cache is required to respond with 504 in this case, not a gate
On 09 May 2013, at 12:36 AM, Roy T. Fielding wrote:
> Unfortunately, I am at the tail end of a long standards meeting and
> haven't slept much for three days. Have you checked to see if the
> descriptions changed in HTTPbis p6? RFC2616 hasn't been relevant
> for a while now.
>
> http://svn.too
On 13 May 2013, at 22:04, Christophe JAILLET
wrote:
> trying to reduce httpd memory usage, I've worked on ap_rgetline_core in
> protocol.c.
>
> This function gets a line of protocol input.
>
> To do so, :
>- it processes the apr_bucket_brigade it is given in parameter, one bucket
> at a
Hi all,
I am currently getting to the bottom of a test case that checks httpd's
response to an abnormally large chunk extension from a reverse proxy server.
What httpd does now is trigger an error, causing both the upstream and
downstream connections to be terminated and truncated. Is this the
Hi all,
I am currently getting a segfault in the proxy during httpd-test, it looks like
conf->mutex is being used before being initialised:
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0010
0x0001007cc8c0 in apr_globa
On 15 May 2013, at 9:48 AM, "Plüm, Rüdiger, Vodafone Group"
wrote:
> This causes new errors / regressions in the test suite.
>
> Failed Test Stat Wstat Total Fail Failed List of Failed
>
> --
On 14 May 2013, at 11:56 PM, Roy T. Fielding wrote:
>> I am currently getting to the bottom of a test case that checks httpd's
>> response to an abnormally large chunk extension from a reverse proxy server.
>> What httpd does now is trigger an error, causing both the upstream and
>> downstream
On 15 May 2013, at 11:05 AM, "Plüm, Rüdiger, Vodafone Group"
wrote:
> # testing : response codes
> # expected: HTTP/1.1 413 Request Entity Too Large
> # received: HTTP/1.1 200 OK
> not ok 7
Found further cases where error messages were being ignored, fixed in r1482918.
Regards,
Graham
--
On 15 May 2013, at 9:23 PM, Ruediger Pluem wrote:
> Now we have:
>
> t/apache/pr17629.t (Wstat: 0 Tests: 4 Failed: 1)
> Failed test: 4
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 wa
On 16 May 2013, at 1:25 AM, Jim Jagielski wrote:
> Ugg. You're 100% right. We need to create a global.
Here is one I made earlier: http://svn.apache.org/r1482859
Regards,
Graham
--
On 16 May 2013, at 3:26 PM, Eric Covener 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?
>
> This is the right place, despite the fact that nobody has shown
> interest in your issu
On 15 May 2013, at 9:23 PM, Ruediger Pluem wrote:
> Now we have:
>
> t/apache/pr17629.t (Wstat: 0 Tests: 4 Failed: 1)
> Failed test: 4
Looking at a verbose version of this test, we see this:
# expected: begin-foobar-end
# received:
#
# 400 Bad Request
#
# Bad Request
# Your browse
On 17 May 2013, at 10:26, Ruediger Pluem 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 proces
On 17 May 2013, at 11:26 AM, Ruediger Pluem 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 pro
On 21 May 2013, at 9:12 PM, Ruediger Pluem wrote:
>> -eos = apr_bucket_eos_create(f->c->bucket_alloc);
>> -APR_BRIGADE_INSERT_TAIL(ctx->proc_bb, eos);
>> +ctx->done = 1;
>> break;
>
> Don't we need to remove the break here as well t
On 22 May 2013, at 1:06 PM, Yann Ylavic wrote:
> On 05/14/2013 08:58 PM, minf...@apache.org wrote:
> > Author: minfrin
> > Date: Tue May 21 16:10:02 2013
> > New Revision: 1484852
> >
> > URL: http://svn.apache.org/r1484852
> > Log:
> > core: Remove apr_brigade_flatten(), buffering and dupli
On 22 May 2013, at 1:48 PM, Yann Ylavic wrote:
> I am not saying that the filter should not tolerate LF only as sperator, but
> that after the chunk (ie. in the BODY_CHUNK_END state) it should only accept
> CRLF (or LF only) and nothing else.
Sure, but the old filter behaved this way, and so t
On 22 May 2013, at 2:47 PM, Yann Ylavic wrote:
> Well, one could inject arbitrary data in this room (with no LF), bypassing
> LimitRequestBody (which does not count chunks separators), and eat resources.
> This opens doors, as often when a protocol is not checked carefully…
Again, this matches
On 22 May 2013, at 3:57 PM, Plüm, Rüdiger, Vodafone Group
wrote:
> I guess you missed a special case:
>
> If the reverse proxy backend sends a response without a Content-Length header
> and without a Transfer-Encoding,
> which is IMHO valid for HTTP 1.0 responses if the connection is closed af
On 22 May 2013, at 4:19 PM, Plüm, Rüdiger, Vodafone Group
wrote:
> Yeah. You are correct. Looks sufficient.
Fixed in r1485257.
Regards,
Graham
--
On 23 May 2013, at 9:58 AM, "Plüm, Rüdiger, Vodafone Group"
wrote:
> Shouldn't we apply the following patch as well to be save that we have a sane
> state
> of b at the beginning of the loop and no remaining buckets e.g. metabuckets
> left in it?
We should, fixed in r1485772.
Regards,
Graham
On 24 May 2013, at 10:38 AM, Thomas Eckert wrote:
> Why would the per_dir_config be NULL here ? I don't think that should ever be
> encountered during the request's lifetime, right ?
I had this recently, and a completely clean rebuild sorted it out.
Regards,
Graham
--
smime.p7s
Description:
901 - 1000 of 1226 matches
Mail list logo
