Re: [RFC] ?
On Tue, Feb 28, 2017 at 5:57 PM, Jacob Champion wrote: > On 02/27/2017 03:19 AM, Joe Orton wrote: >> >> On Wed, Feb 22, 2017 at 10:00:08PM +0100, Yann Ylavic wrote: >>> >>> On Wed, Feb 22, 2017 at 11:47 AM, Joe Orton wrote: (b) for match both "foo" and ">> >>> >>> I'd vote for this, it's very unlikely that some day we want to add a >>> directive called VirtualHost or If (w/o the leading '<') which may >>> conflict here, so it shouldn't hurt. >> >> >> I'm fine with that, I'll commit like this unless anybody else has strong >> opinions. > > > mod_lua (in trunk at least) apparently ships both a '' and 'LuaXXX' > version of several directives. It wouldn't surprise me to find that other > third-party modules have a "block version" of a normal directive with the > same name. I'm kind of -0.5 to making the two collide. > > Is there a good reason that quoting the argument to a block gives a syntax > error? Can we fix that instead? As much as we all suck at naming things... What about vs. ? (And deliberately circumvent anyone using
Re: [RFC] ?
On 02/28/2017 04:09 PM, Eric Covener wrote: But even if it wasn't, you'd also have to be interested in one being available when the other isn't, for it to affect Right. My concern is mostly for the following situation: - module author provides a ModuleDirective in v1 - author realizes that a block version of said directive would make a lot of sense - author releases in v2 - everyone eventually figures out, after wailing and gnashing of teeth, that they can't use to differentiate between the two I definitely don't think this will be common. I just don't like hamstringing a nice new directive with what's effectively a (rare) bug. --Jacob
Re: [RFC] ?
On Tue, Feb 28, 2017 at 6:57 PM, Jacob Champion wrote: > mod_lua (in trunk at least) apparently ships both a '' and 'LuaXXX' > version of several directives. It wouldn't surprise me to find that other > third-party modules have a "block version" of a normal directive with the > same name. I'm kind of -0.5 to making the two collide. I think it would still be pretty rare. But even if it wasn't, you'd also have to be interested in one being available when the other isn't, for it to affect -- Eric Covener cove...@gmail.com
Re: [RFC] ?
On 02/27/2017 03:19 AM, Joe Orton wrote: On Wed, Feb 22, 2017 at 10:00:08PM +0100, Yann Ylavic wrote: On Wed, Feb 22, 2017 at 11:47 AM, Joe Orton wrote: (b) for match both "foo" and " I'd vote for this, it's very unlikely that some day we want to add a directive called VirtualHost or If (w/o the leading '<') which may conflict here, so it shouldn't hurt. I'm fine with that, I'll commit like this unless anybody else has strong opinions. mod_lua (in trunk at least) apparently ships both a '' and 'LuaXXX' version of several directives. It wouldn't surprise me to find that other third-party modules have a "block version" of a normal directive with the same name. I'm kind of -0.5 to making the two collide. Is there a good reason that quoting the argument to a block gives a syntax error? Can we fix that instead? --Jacob
Re: httpd 2.4.25, mpm_event, ssl: segfaults
All writes to Linux sockets means the kernel copies to 2kiB buffers used by SKBs. It's copied to somewhere in the middle of that 2kiB buffer, so that TCP/IP headers can be prepended by the kernel. Even with TCP Segmentation Offload, 2kiB buffers are still used; it just means that the TCP/IP headers just need to be calculated once for an array of buffers, and then the kernel puts an array of pointers in the network card's ring buffer. The kernel will only put on the wire as much data as the current TCP congestion window says, but it has to keep each packet in it's buffers until the remote side ACKs that packet. On Mon, Feb 27, 2017 at 2:25 PM, William A Rowe Jr wrote: > On Mon, Feb 27, 2017 at 12:16 PM, Jacob Champion > wrote: > > > > On 02/23/2017 04:48 PM, Yann Ylavic wrote: > >> On Wed, Feb 22, 2017 at 8:55 PM, Daniel Lescohier wrote: > >>> > >>> > >>> IOW: read():Three copies: copy from filesystem cache to httpd > >>> read() buffer to encrypted-data buffer to kernel socket buffer. > > > >> > >> Not really, "copy from filesystem cache to httpd read() buffer" is > >> likely mapping to userspace, so no copy (on read) here. > > > > Oh, cool. Which kernels do this? It seems like the VM tricks would have > to > > be incredibly intricate for this to work; reads typically don't happen in > > page-sized chunks, nor to aligned addresses. Linux in particular has > > comments in the source explaining that they *don't* do it for other > syscalls > > (e.g. vmsplice)... but I don't have much experience with non-Linux > systems. > > I don't understand this claim. > > If read() returned an API-provisioned buffer, it could point wherever it > liked, > including a 4k page. As things stand the void* (or char*) of the read() > buffer > is at an arbitrary offset, no common OS I'm familiar with maps a page to > a non-page-aligned address. > > The kernel socket send[v]() call might avoid copy in the direct-send case, > depending on the implementation. >
Re: HttpProtocolOptions Directive
On Tue, Feb 28, 2017 at 2:50 AM, Pavel Reichl wrote: > Hello, > > I have a question regarding this new directive - HttpProtocolOptions and in > particular its parameter Unsafe. > > From https://httpd.apache.org/docs/2.4/mod/core.html: > ...Due to legacy modules, applications or custom user-agents which must be > deprecated the Unsafe option has been added to revert to the legacy > behaviors. > > What exactly are supported deprecated behaviors? I noticed some formats that > worked in 2.4.23 but do not work in 2.4.25 even with Unsafe. > > Among others: > * Only SP is now supported as separator in request line - but it used to > work with TAB and some other white space as well. (Although more than one SP > can still be used.) > * Neither SP nor TAB are allowed between header name and colon. > > Can you please confirm that this is intended behavior? Hi Pavel, yes, some specific requirements which had been present since RFC 2068 (published 20 years ago last month) or mandated by the RFC7230 series of specifications, were considered by the httpd project, in the form of either an UnsafeWhitespace option or yet another legacy property of Unsafe. The three which were resoundingly rejected for legacy preservation are the two you mention, SP in the request line (other whitespace characters such as carriage return, form feed and vertical tab had been equally acceptable), as well as CR+LF being the only recognized line seperator, both of which have been clearly required by the spec all the way back to RFC 2068, as well as no whitespace following the header name before the colon which is a MUST implement per RFC 7230. All three of these avert demonstrated security vulnerabilities which may split requests or responses when passing between HTTP proxies which have a different tolerance or interpretation of whitespace. This in turn may lead to cache pollution or information disclosure, similar to the lingering risks posed by cloudbleed. As stated in the docs for this directive; "the strict whitespace suggested by [RFC7230] section 3.5 is enforced and cannot be relaxed." Hope this clarifies any confusion for you.
Re: release v1.9.2
Meh, my mistake. Sorry about that. Did not cleanup properly. Dare you with an improved version: h2_192_alloc_mutex_v2.diff Description: Binary data > Am 28.02.2017 um 08:41 schrieb Stefan Priebe - Profihost AG > : > > That one breaks everyting. Multiple crashes per second. > > [Thread debugging using libthread_db enabled] > Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". > Core was generated by `/usr/local/apache/bin/httpd -DFOREGROUND'. > Program terminated with signal SIGABRT, Aborted. > #0 0x7f02724ea067 in raise () from /lib/x86_64-linux-gnu/libc.so.6 > #0 0x7f02724ea067 in raise () from /lib/x86_64-linux-gnu/libc.so.6 > #1 0x7f02724eb448 in abort () from /lib/x86_64-linux-gnu/libc.so.6 > #2 0x7f02724e3266 in ?? () from /lib/x86_64-linux-gnu/libc.so.6 > #3 0x7f02724e3312 in __assert_fail () from > /lib/x86_64-linux-gnu/libc.so.6 > #4 0x7f027287062f in __pthread_tpp_change_priority () > from /lib/x86_64-linux-gnu/libpthread.so.0 > #5 0x7f0272865e9f in __pthread_mutex_lock_full () > from /lib/x86_64-linux-gnu/libpthread.so.0 > #6 0x7f0272a98db8 in allocator_alloc (in_size=in_size@entry=8032, >allocator=0x7f025c03f3c0) at memory/unix/apr_pools.c:244 > #7 apr_allocator_alloc (allocator=0x7f025c03f3c0, size=size@entry=8032) >at memory/unix/apr_pools.c:438 > #8 0x7f0272cbcac4 in apr_bucket_alloc (size=8032, size@entry=8000, >list=0x7f022c0008e8) at buckets/apr_buckets_alloc.c:157 > #9 0x7f0272cbdca2 in socket_bucket_read (a=0x7f022c000b08, >str=0x7f02627a87b8, len=0x7f02627a87c0, block=) >at buckets/apr_buckets_socket.c:34 > #10 0x565098cf1fb1 in ap_core_input_filter (f=0x7f022c0056b0, >b=0x7f022c005630, mode=, block=APR_NONBLOCK_READ, >readbytes=5) at core_filters.c:235 > #11 0x565098d3aaca in logio_in_filter (f=, >bb=0x7f022c005630, mode=, block=, >readbytes=) at mod_logio.c:165 > #12 0x565098d45b9a in bio_filter_in_read (bio=0x7f024800b460, >in=0x7f02480492a3 "", inlen=5) at ssl_engine_io.c:483 > #13 0x7f02736b014c in BIO_read () > from /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0 > #14 0x7f0273a13c92 in ?? () from > /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0 > #15 0x7f0273a1548d in ?? () from > /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0 > #16 0x7f0273a12024 in ?? () from > /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0 > #17 0x565098d469f3 in ssl_io_input_read (inctx=0x7f022c0035b8, >buf=0x7f022c003600 "GET > /media/image/07/3c/c2/4612_13721_160192280322.jpeg HTTP/1.1\r\nHost: > www.onlinestore.it\r\nUser-Agent: curl/7.15+ (x64-criteo) libcurl/7.15+ > OpenSSL zlib libidn\r\nAccept: */*\r\n\r\n", len=0x7f02627a8b38) >at ssl_engine_io.c:614 > #18 0x565098d493ec in ssl_io_filter_input (f=0x7f022c005608, >bb=0x7f022c006dd0, mode=, block=, >readbytes=8000) at ssl_engine_io.c:1474 > #19 0x565098d5cd85 in h2_filter_core_input (f=0x7f022c005980, >brigade=0x7f022c006dd0, mode=738225624, block=APR_NONBLOCK_READ, >readbytes=8000) at h2_filter.c:149 > #20 0x565098d6809b in h2_session_read (session=0x7f022c006920, >block=) at h2_session.c:1440 > #21 0x565098d6b97f in h2_session_process (session=0x7f022c006920, >async=3964) at h2_session.c:2074 > #22 0x565098d5b84e in h2_conn_run (ctx=, > c=0x7f025c03f7d8) >at h2_conn.c:218 > #23 0x565098d5e551 in h2_h2_process_conn (c=0x7f025c03f7d8) at > h2_h2.c:658 > #24 0x565098d00fd0 in ap_run_process_connection (c=0x7f025c03f7d8) >at connection.c:42 > #25 0x565098d9b6d0 in process_socket (my_thread_num=, >my_child_num=, cs=0x7f025c03f748, sock=, >p=, thd=) at event.c:1134 > #26 worker_thread (thd=0xf5e, dummy=0xf7c) at event.c:2137 > #27 0x7f02728680a4 in start_thread () > from /lib/x86_64-linux-gnu/libpthread.so.0 > #28 0x7f027259d62d in clone () from /lib/x86_64-linux-gnu/libc.so.6 > (gdb) (gdb) quit > Reading symbols from /usr/local/apache/bin/httpd...Reading symbols from > /usr/lib/debug//usr/local/apache2/bin/httpd...done. > done. > [Thread debugging using libthread_db enabled] > Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". > Core was generated by `/usr/local/apache/bin/httpd -DFOREGROUND'. > Program terminated with signal SIGABRT, Aborted. > #0 0x7f02724ea067 in raise () from /lib/x86_64-linux-gnu/libc.so.6 > #0 0x7f02724ea067 in raise () from /lib/x86_64-linux-gnu/libc.so.6 > #1 0x7f02724eb448 in abort () from /lib/x86_64-linux-gnu/libc.so.6 > #2 0x7f02724e3266 in ?? () from /lib/x86_64-linux-gnu/libc.so.6 > #3 0x7f02724e3312 in __assert_fail () from > /lib/x86_64-linux-gnu/libc.so.6 > #4 0x7f027287062f in __pthread_tpp_change_priority () > from /lib/x86_64-linux-gnu/libpthread.so.0 > #5 0x7f0272865e9f in __pthread_mutex_lock_full () > from /lib/x86_64-linux-gnu/libpthread.so.0 > #6 0x7f0272a98db8 in allocator_alloc (in_size=in_size@entry=8032, >alloca
Re: HttpProtocolOptions Directive
On Tue, 2017-02-28 at 09:50 +0100, Pavel Reichl wrote: > Hello, > > > I have a question regarding this new directive - HttpProtocolOptions > and in particular its parameter Unsafe. Basically the HTTP spec changed. RFC7230 outlaws behaviours that were fine under earlier HTTP versions. Apache HTTPD, along with other web software, is being updated to the new standard. Unsafe should get you legacy behaviour unless the docs and CHANGES say otherwise. If you're getting discrepancies, that's probably worth a bug report. -- Nick Kew
HttpProtocolOptions Directive
Hello, I have a question regarding this new directive - HttpProtocolOptions and in particular its parameter Unsafe. >From https://httpd.apache.org/docs/2.4/mod/core.html: ...Due to legacy modules, applications or custom user-agents which must be deprecated the Unsafe option has been added to revert to the legacy behaviors. What exactly are supported deprecated behaviors? I noticed some formats that worked in 2.4.23 but do not work in 2.4.25 even with Unsafe. Among others: * Only SP is now supported as separator in request line - but it used to work with TAB and some other white space as well. (Although more than one SP can still be used.) * Neither SP nor TAB are allowed between header name and colon. Can you please confirm that this is intended behavior? Thanks! Best regards, Pavel Reichl
