Backported in 1844223, will be part of 2.4.37.
Thanks again!
Rainer
Great! Thanks a lot for proposing & backporting.
Regards,
Michael
Hi,
there's a bug in the current 2.4.x branch of httpd which leads to
crashes for SSL renegotiations.
The variable "ctx" is always NULL in ssl_engine_kernel.c,
ssl_hook_Access_classic(), and it's used here:
if (!(cert_store ||
(cert_store = SSL_CTX_get_cert_store(ctx
...
In trunk
Hi Stefan,
Yes, the patch solves the problem for me :-) Thanks a bunch!
Regards,
Michael
Zitat von Stefan Eissing :
Michael, I can reproduce the problem and habe a fix. Can you test if
the following patch also solves the problem for you? Thanks!
Index: modules/http2/h2_mplx.c
Hi,
I have found a regression in mod_http2. When the client stops sending
data and closes the connection, mod_http2 doesn't detect that the
client has left and continues to "read" request data (until the
request times out because of the server's TimeOut value).
The bug has been introduced
Zitat von Stefan Eissing :
Withdrawn the proposal in r1747668 after reading the comment from Roy again.
Apache is the only HTTP/2 server in this world that sends this strange
header. So omitting it would be the right thing to do.
Michael, since you know more about this: is there a specific
Zitat von William A Rowe Jr :
Skimming the responses, they just keep getting more and more amusing, and
shining a candle to the absurdity of keeping this non-sequitur request
response.
Could you go ahead and add that conditional?
To all developers who participated in this discussion: Please
Zitat von Stefan Eissing :
Thanks for the patch! I applied it to trunk in r1743335, will be part of next
1.5.4 release. I only omitted the last change as I do not want to set aborted
on the main connection every time the session closes.
Ok, that's fine for me. Thanks a lot Stefan!
Regards,
Mi
Zitat von William A Rowe Jr :
On Wed, May 4, 2016 at 3:44 PM, Michael Kaufmann
wrote:
William is right, this is not a good idea. The ->aborted flag should serve
this purpose of telling anyone interested that this connection is not
longer delivering. I will make a github release soon wh
William is right, this is not a good idea. The ->aborted flag should
serve this purpose of telling anyone interested that this connection
is not longer delivering. I will make a github release soon where
that is working and you can test.
Thank you Stefan! It is now working for stream rese
Zitat von William A Rowe Jr :
On Tue, May 3, 2016 at 9:31 AM, Michael Kaufmann
wrote:
Hi all,
a content generator module can detect client aborts and stream resets
while it reads the request body. But how can it detect this afterwards,
while the response is being generated?
This is
Hi,
It would be great if somebody could have a look at the proposed patch.
The problem: Request headers are adjusted too late (in the input filter).
Proposed solution: Adjust the request headers in the filter init function.
https://bz.apache.org/bugzilla/show_bug.cgi?id=54255
Regards,
Michael
Hi all,
a content generator module can detect client aborts and stream resets
while it reads the request body. But how can it detect this
afterwards, while the response is being generated?
This is important for HTTP/2, because the client may reset a stream,
and mod_http2 needs to wait for
Done in r1740075.
I think that commit introduced a small bug, because the "for" loop is
left when "h2" is seen and "report_all" is false. There may be other
protocols that are more preferred than the current one.
Suggested change:
Index: server/protocol.c
===
Zitat von Stefan Eissing :
Done in r1740075.
I was thinking of a nicer solution, but that involved inventing new
hooks which seems not worth it.
Since this area of protocol negotiation has already been talked
about in regard to TLS upgrades and websockets, I do not want to
invest in the
On Tue, Apr 19, 2016 at 8:57 AM, Michael Kaufmann
wrote:
Yes, you are right. But with the response header "Upgrade: h2", Apache is
telling the client "you may send such a header" when in fact this is not
allowed.
Devils advocate: Apache is telling the client at the a
On Tue, Apr 19, 2016 at 8:47 AM, Michael Kaufmann
wrote:
I think that this is wrong, because of this sentence in RFC 7540:
A server MUST ignore an "h2" token in an Upgrade header field. Presence of
a token with "h2" implies HTTP/2 over TLS, which is instead negotiated as
Hi,
you may already know that HTTP/2 clients use ALPN to advertise support
for HTTP/2 when TLS is used.
The issue is this: When mod_http2 is enabled, Apache sends an
"Upgrade: h2" response header to clients that have *not* advertised
support for HTTP/2 (clients that speak only HTTP/1.x).
Eric Covener wrote:
On Sat, Mar 19, 2016 at 11:31 AM, Michael Kaufmann
wrote:
I have found a bug in the current 2.4.x branch: "SetHandler None" does not
work anymore (note the capital letter "N"). This worked with Apache 2.4.18.
Probably this commit has change
Hi,
I have found a bug in the current 2.4.x branch: "SetHandler None" does
not work anymore (note the capital letter "N"). This worked with Apache
2.4.18. Probably this commit has changed the behavior:
http://svn.apache.org/r1729876
The documentation at
https://httpd.apache.org/docs/2.4/en/
Hi,
in bug 57044, I proposed to use base64url for UNIQUE_ID. This means
that the character '_' shall be used instead of '@', because '@' is
not URL-safe. '_' is, and it may be used without percent-encoding in
URLs, HTTP headers, or cookie values.
What do you think? Does anyone dare to com
Thanks for reporting this before the testing/release.
Fixed in r1688274 (will now propose a backport), and since this is a
showstopper, it will be merged (once reviewed) before 2.4.16/2.2.30.
Proposed patch (for backport) is
http://people.apache.org/~ylavic/httpd-2.4.x-fix_LimitRequestBody.patch
Hi,
LimitRequestBody is broken in the (unreleased) Apache versions
2.4.13-2.4.15 because of this change: http://svn.apache.org/r1684515
In http_filters.c, ap_http_filter(): The variable "totalread" is
uninitialized if readbytes is 0.
Messages similar to this one are logged: "AH01591: Read
On Thu, Jan 22, 2015 at 8:27 AM, Michael Kaufmann
wrote:
Hi,
It would be great if somebody finds time to review the proposed patch for
bug 57100 (and maybe commit it to trunk). Any feedback would be greatly
appreciated.
-> https://issues.apache.org/bugzilla/show_bug.cgi?id=57100
Tha
Hi,
It would be great if somebody finds time to review the proposed patch
for bug 57100 (and maybe commit it to trunk). Any feedback would be
greatly appreciated.
-> https://issues.apache.org/bugzilla/show_bug.cgi?id=57100
Regards,
Michael
24 matches
Mail list logo
