Re: Is Apache getting too patchy?

On 10/26/2015 03:40 PM, Tim Bannister wrote: On 26 Oct 2015, at 22:23, Nick Kew wrote: I wonder if workflow would be improved if we had named maintainers for particular parts of the codebase - for example individual modules? Not necessarily to do all the work, but to take

Re: Is Apache getting too patchy?

On 10/26/2015 03:23 PM, Nick Kew wrote: On Mon, 26 Oct 2015 09:51:43 -0700 Jacob Champion <champio...@gmail.com> wrote: I'd rather not feel like I'm just annoying dev@ until you submit my stuff -- I want to *talk* about it, and improve the server. That may not be easy. You need t

Re: Is Apache getting too patchy?

On 10/27/2015 03:26 AM, Graham Leggett wrote: On 27 Oct 2015, at 12:40 AM, Tim Bannister wrote: That may not be easy. You need to find someone who'll be interested in an idea or patch, and has the time to review it. Plus, the community as a whole to agree it's a good

Re: Enforce rewriting of Host header when an absolue URI is given

Yann, I found this while trying to understand the corner cases for Origin header checks for mod_websocket, and I do actually have some thoughts on it... On 03/04/2015 07:21 AM, Yann Ylavic wrote: (by default, not only with "HttpProtocol strict", which is trunk only btw). Per

Re: Is Apache getting too patchy?

On 10/24/2015 09:32 PM, Kurtis Rader wrote: People reviewing changes to the existing code base have to be hard-nosed assholes. Kurtis, I agree with everything you said except this. IMHO, you've traded one bad extreme (where few people care about the quality of the codebase) for another

Re: Is Apache getting too patchy?

On 10/24/2015 08:49 AM, Jim Jagielski wrote: Thoughts? Comments? Jim, I'm somewhat on the outside looking in, as an httpd newbie. But my standard experience (it's happened two or three times now) is this: 1) Non-trivial patch is proposed to the list with calls for discussion/debate. 2)

Re: Is Apache getting too patchy?

On 10/26/2015 10:52 AM, Kurtis Rader wrote: Asshole was probably not the best term. I meant it in the sense that you shouldn't be afraid to tell someone in plain language what the problems are with their proposed change. Yes, the reviewer should be polite. No, they should not sugar-coat their

Re: Interesting data point

On 11/12/2015 12:35 AM, William A Rowe Jr wrote: If it is that easy to move 202k sites (111k net) to an entirely different server, it is supposed to be much simpler for the users to move within the same server - from their 2.2.x to 2.4.current, isn't it? And if it is that easy to move away,

mod_websocket cross-post

Hi all, (If you're already subscribed to modules-dev@ or users@, you've already seen this -- sorry -- but Rich Bowen suggested that I post here as well.) I recently released a 0.1.0 version of mod_websocket, which was at one point [1] under consideration for folding into the httpd project,

Re: Is Apache getting too patchy?

On 10/29/2015 11:05 PM, Christophe JAILLET wrote: To give you some ideas of what can be looked at easily by new comers: Hi Christophe, Thanks for the list! Is there any way to get these into the STATUS, or into a document that the STATUS points to? (The current "Contributors looking for a

Re: [PATCH 57300] mod_session save optimization

On 10/15/2015 01:53 PM, Paul Spangler wrote: Bump in case anyone is interested now that the list has died down a bit. I'm a little biased :) but I am still interested. From a practical angle, Paul's patch makes session-based applications usable with databases that have more expensive writes

Re: 2.4.17 alignment issue sparc/ia64

On 10/15/2015 08:53 PM, Eric Covener wrote: We recently merged 2.4.17 and saw some bus errors on hp/ia64 and solaris/sparc64. Selectively backing things out, it appears that the SO_REUSEPORT patch causes the worker_score to no longer (necessarily) be double-word aligned. I don't have any

Re: 2.4.17 alignment issue sparc/ia64

On 10/15/2015 11:18 PM, Jacob Champion wrote: it looks like ap_init_scoreboard() doesn't try to maintain any particular alignment when it's assigning pointers from more_storage. Though one would think your compiler would be padding out the struct to a double-word multiple anyway. Hrm

Re: Non-blocking ap_get_brigade() doesn't return EAGAIN?

On 10/19/2015 01:07 PM, Yann Ylavic wrote: I'll (re)take a look at the thread [2] you mentioned (and refresh my mind, I don't remember all the details :), and then propose something to dev@... Great, thanks! Looking forward to the discussion. --Jacob

Re: No luck with `Protocols h2`

work Headers panel is the "Version: HTTP/2.0" field that is underneath the Status Code and above the search bar. Am 10.10.2015 um 02:24 schrieb Jacob Champion <champio...@gmail.com>: (Haven't figured out the nghttp failure yet though.) Thanks Gregg! For those following at home,

Double 101 response on timeout with h2c/mod_http2

I was curious to see how the mod_reqtimeout filter removal worked with mod_http2, since mod_websocket needs something similar. So I opened up telnet and did a manual Upgrade: h2c with some junk HTTP2-Settings. I got the 101 Switching Protocols response and a binary chunk of SETTINGS, then let

Re: 2.4.17 test failure for mod_nntp_like_ssl when mod_http2 is loaded

On 10/12/2015 02:12 AM, Yann Ylavic wrote: That would be better, but still the doc says "[H2Direct] falls outside the RFC 7540 but has become widely implemented as it is very convenient for development and testing". _Does_ it fall outside the RFC? Section 3.4 covers the establishment of

No luck with `Protocols h2`

Stefan, I'm trying to test mod_http2 for the 2.4.17 release, but I cannot for the life of me get ALPN and the h2 protocol working together. h2c seems to work, as does http/1.1 over TLS. My hope is that I'm just missing a config directive somewhere; can anyone else confirm that h2 negotiation

Re: No luck with `Protocols h2`

On 10/09/2015 05:11 PM, Gregg Smith wrote: I have no real recommendation for you but the RFC states all implementations must support TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 or OpenSSL's equivalent ECDHE-RSA-AES128-GCM-SHA256. So it's a starting point. Perfect! After pulling it up front with

Re: mod_h2 / ssl warnings Windows

On Thursday, September 17, 2015, Steffen wrote: > > For you info, warnings when build with VC14 Win64. > > See attached. > > The size_t/int and pointer/int warnings show up in a large number of modules on Win64, IIRC. Is there already an established opinion on whether or

Re: svn commit: r1705681 - in /httpd/httpd/branches/2.4.17-protocols-http2: ./ docs/manual/mod/ docs/manual/rewrite/ modules/filters/ modules/loggers/ modules/ssl/ server/

On 09/28/2015 06:00 AM, j...@apache.org wrote: Author: jim Date: Mon Sep 28 13:00:59 2015 New Revision: 1705681 URL: http://svn.apache.org/viewvc?rev=1705681=rev Log: Sync [...] Modified: httpd/httpd/branches/2.4.17-protocols-http2/modules/ssl/ssl_engine_kernel.c URL:

Thoughts on the new Protocols architecture

Hi all, At Stefan's suggestion, I took a look at the new Upgrade-related hooks with the Protocols directive, and I tried to get mod_websocket to use the same machinery as an experiment. I have some thoughts and questions based on that -- hopefully they're of interest and/or use to you. ==

Re: Thoughts on the new Protocols architecture

Stefan, On 09/21/2015 05:00 AM, Stefan Eissing wrote: I think a "protocol_ugprade" hook would work better. That way, a module like yours can replace the core upgrade handling itself, send your own 101 response and call ap_switch_protocol() yourself. Would that work for you? Yes, a separate

Re: 2.4 pause - mod_http2 patchset Upgrade h2c vs mod_ssl Upgradetls

On 12/08/2015 01:42 AM, Stefan Eissing wrote: If Apache accepts body lengths of up to 64KB (or something configurable) and some other server implements 8K and some third 1MB, how will that help design of a client that, for some reason, *wants* an upgrade to succeed? I don't disagree with your

Re: Upgrade Summary

On 12/08/2015 02:07 AM, Stefan Eissing wrote: C. if a protocol supports upgrade on request bodies is up to the protocol implementation and needs to be checked in the "propose" phase Only if the module's intent is to simply ignore upgrade requests if they have bodies. Other modules might

Re: On the Upgrade request body limit

On 12/08/2015 12:45 PM, Jim Jagielski wrote: Well We are not NGINX. We are also not Microsoft. We don't create HTTP response codes willy-nilly. We actually try to *honor* the actual specs. Yes, I agree 100%. :) Trust me, I've dealt with enough non-standard HTTP "extensions"; I'm not

On the Upgrade request body limit

I wrote this in response to Stefan's note on the zero-length request body limit for h2c Upgrades, then realized it would further fragment the (already massive) conversation, so here it is. Stefan wrote: It is possible, but difficult to do unless you can read the body and > set it aside

Re: On the Upgrade request body limit

On 12/08/2015 03:01 PM, Yann Ylavic wrote: Jacob, On Tue, Dec 8, 2015 at 11:17 PM, Yann Ylavic wrote: As I read the RFC, the simple(st) case is: Request (upgrade: somespec) -> request body <- 101 (upgrade: somespec) <- new protocol response or read Wouldn't that work

Re: On the Upgrade request body limit

On 12/08/2015 02:00 PM, William A Rowe Jr wrote: Apache httpd server offers limits on the number of incoming headers, the number of bytes in those headers, the number of bytes in the request line, the length of the URI. The maximum request body length. This is just one more limit, but not an

Re: Upgrade Summary

On 12/08/2015 01:03 PM, Jacob Champion wrote: - The module that won the proposal is given one last chance to check the incoming request and fail the upgrade with an immediate HTTP response. And to add to this, for completeness: mod_websocket also needs to add any required headers (e.g. Sec

Re: Upgrade Summary

On 12/08/2015 02:30 AM, Bert Huijben wrote: The TLS and H2C upgrades both begin in one form and end in a different form. Websockets are kind of different in that they require a bad request response in a specific case. I'm not sure in which protocol this error needs to be send though. For

Re: 2.4 pause - mod_http2 patchset Upgrade h2c vs mod_ssl Upgrade tls

Ugh, looks like I'm too slow on my work with the upgrade proposal hooks; sorry I haven't been able to give in-depth feedback yet. On Dec 7, 2015 11:09 AM, "Stefan Eissing" wrote: > > Not at my machine to really check the runtime behaviour. Can do that tomorrow. My

Re: 2.4 pause - mod_http2 patchset Upgrade h2c vs mod_ssl Upgrade tls

On Dec 7, 2015 8:43 AM, "William A Rowe Jr" wrote: > > https://tools.ietf.org/html/rfc7230#section-6.7 makes things more interesting, it calls out that 101-continue and the request body read precedes the 101-switching protocols. Not sure who decided that would be a good

Re: 2.4 pause - mod_http2 patchset Upgrade h2c vs mod_ssl Upgrade tls

On Dec 7, 2015 12:44 PM, "Stefan Eissing" wrote: > > There can be no 100 after a 101. After a 101, the downstream speaks the new protocol, immediately. I suspect Bill is talking about the very specific case of an upgrade to HTTP/1.1-over-TLS, in which case I think

Re: 2.4 pause - mod_http2 patchset Upgrade h2c vs mod_ssl Upgrade tls

On 12/07/2015 11:55 AM, Jacob Champion wrote: > - moving things to post read sounds tempting, however I'm not sure if we want to upgrade on non-authed request or not, for example. I am not sure what else we do in post read, maybe someone else has an opinion about that. It certainly looks ni

Re: AW: 2.4 pause - mod_http2 patchset Upgrade h2c vs mod_ssl Upgradetls

On 12/07/2015 02:30 PM, Bert Huijben wrote: Is this a h2 limitation or a mod_h2 limitation? If I would like h2c upgrade from Subversion without an additional request I would have to send the upgrade request with a very short OPTIONS request that has a body. The HTTP/2 spec (RFC 7540, sec 3.2)

Re: 2.4 pause - mod_http2 patchset Upgrade h2c vs mod_ssl Upgrade tls

On 12/07/2015 02:40 PM, William A Rowe Jr wrote: Not "noise" at all... I'm imagining a mod_echo protocol example that looks much like your use case... 1st call to core_upgrade_request in post_read_req hook, after setenvif and mod_headers processing... tls is ready, echo (or websocket) would not

Re: 2.4 pause - mod_http2 patchset Upgrade h2c vs mod_ssl Upgrade tls

On 12/07/2015 03:49 PM, William A Rowe Jr wrote: Just to confirm, the purpose of splitting this up into two separate calls to the same function is solely to deal with "OPTIONS *", which doesn't follow the same logical path in httpd? Or is there another reason? No, it is because

Re: Upgrade Summary

On 12/09/2015 03:19 PM, William A Rowe Jr wrote: Because the request body is inbound already at some state of completion or incomplete transmission, it is competing with the TLS handshake, which is a bidirectional engagement with the same socket between the user agent and server. Unlike h2c and

Re: Upgrades

On 12/09/2015 04:16 PM, Tim Bannister wrote: Any subsequent requests on the same TCP connection won't be eligible for upgrade to WebSocket. Why not? --Jacob

Re: Upgrade Summary

On 12/09/2015 05:19 PM, William A Rowe Jr wrote: The "handler phase" is simply the establishment of a bidirectional WebSocket connection. If the client did something pathological like sending a request body with their GET request, I think that needs to go into the bit bucket

Re: Upgrade Summary

On 12/10/2015 02:45 AM, Bert Huijben wrote: Websockets are different… and in some ways not really an upgrade of the connection… more like a hostile takeover with a final operation to a target Ha! Yes -- although from the point of view of HTTP/1.1, all successful upgrades are hostile

Re: Upgrade Summary

Okay, I finally have actual code to share. This is the original experimental pre_protocol_switch hook that Stefan and I were talking about a while ago [1], rebased onto 2.4.18. The two patches are available at https://github.com/jchampio/httpd/commits/dev/websocket-protocols It is *not*

Re: Upgrade Summary

n 12/11/2015 02:24 PM, William A Rowe Jr wrote: On Fri, Dec 11, 2015 at 2:55 PM, Jacob Champion <champio...@gmail.com <mailto:champio...@gmail.com>> wrote: That additional constraint doesn't conflict with any part of HTTP/1.1, as far as I can tell. Returning 4xx directly t

Re: Upgrade Summary

On 12/09/2015 09:17 AM, William A Rowe Jr wrote: On Tue, Dec 8, 2015 at 9:10 PM, Roy T. Fielding > wrote: > On Dec 8, 2015, at 2:07 AM, Stefan Eissing > wrote: > >

Re: Upgrade Summary

On 12/11/2015 02:36 AM, Bert Huijben wrote: -Original Message- From: Stefan Eissing [mailto:stefan.eiss...@greenbytes.de] Protocol implementations should make up their minds in the "propose" phase, I think, because once a protocol gets selected, the upgrade *should* succeed unless the

Re: Upgrade Summary

On 12/11/2015 12:12 PM, William A Rowe Jr wrote: On Fri, Dec 11, 2015 at 1:13 PM, Jacob Champion <champio...@gmail.com <mailto:champio...@gmail.com>> wrote: On 12/11/2015 02:36 AM, Bert Huijben wrote: Not upgrading is 100% better than failing. ...except for tho

Re: apr_token_* conclusions (was: Better casecmpstr[n]?)

On Nov 25, 2015 1:10 PM, "Jim Jagielski" wrote: > ... I think we are WAY overthinking naming here. I overthink naming constantly, so there's an excellent chance that you're absolutely correct! That said... your list only ended up convincing me that APR needs better naming

Re: apr_token_* conclusions (was: Better casecmpstr[n]?)

My two cents: I agree that another "name mangled" abbreviation is not particularly helpful, but I also agree with Jim's concern: "apr_token" made me immediately wonder what made this exclusive to HTTP tokens. Unfortunately I don't have much of an alternative suggestion. I have seen other

Re: mod_macro: Control on bad nesting

On 06/03/2016 07:19 AM, Eric Covener wrote: Maybe a global directive to turn off the nesting check? Or a convention for the macro name? Or a second tag like (bad name) that is a very thin wrapper around existing stuff? Would a MacroOptions (or similar) as the first directive inside a

Re: Multiple patches; any takers before T?

On 06/10/2016 05:01 AM, Jim Jagielski wrote: Thx! Are any of these in trunk, or are they 2.4-branch specific? None of these are currently committed to trunk, but all the patches should apply cleanly (or at least, they do for me, on a trunk from sometime yesterday). The majority of my

Multiple patches; any takers before T?

Hi all, It may be too late now that the T machinery is in motion, but I'll bump some of my patchsets: - APXS: https://bz.apache.org/bugzilla/show_bug.cgi?id=58926 Quality-of-life improvements for users of the APXS tool, as well as some code cleanup for the script itself. - DUMP_INCLUDES:

Re: svn commit: r1748327 - in /httpd/httpd/branches/2.4.x: ./ CHANGES STATUS server/config.c server/core.c server/main.c

On 06/14/2016 11:19 PM, Christophe JAILLET wrote: this worse a doc update somewhere. Is there a page where such parameters are described? I've only found [1], but expected a more comprehensive list. I wasn't able to find anything either, except for the -h output for httpd, which is still

Re: Multiple patches; any takers before T?

On 06/12/2016 06:35 AM, Jim Jagielski wrote: After the T, I will apply to trunk and then they will be available for backport next time (assuming no issues w/ the patches, 'natch) Thanks Jim! It looks like two of the four (DUMP_INCLUDES and proxy:fcgi) were applied to trunk over the weekend.

Re: Module Development - Advice Needed

On 05/26/2016 08:18 PM, William A Rowe Jr wrote: The users list is the best place to ask for clarification and guidance, users are not exclusively admins, they include module authors, troubleshooters, even a testing community. In addition to users@, there is also a modules-dev@ list for httpd.

Re: [VOTE] Release Apache httpd 2.4.21 as GA

> [x] +1: Good to go Built: Ubuntu 14.04 (x64): apr-2, openssl-1.0.2d, nghttp2-1.8.0 Ubuntu 16.04 (x64): apr-1.5.2, apu-1.5.4, openssl-1.0.2g, nghttp2-1.10.0 Windows 7 (x64, MSVC14): apr-2, openssl-1.0.2g, nghttp2-1.8.0 Windows 10 (x64, MSVC14): apr-2, openssl-1.0.2h,

Re: "Upgrade: h2" header for HTTP/1.1 via TLS (Bug 59311)

On 06/15/2016 01:32 PM, William A Rowe Jr wrote: It seems to me that we -can- implement Connection: Upgrade Upgrade: h2 on a plaintext connection, which is simply shorthand for Upgrade: TLS/1.x, HTTP/2 where the TLS connection *must* handshake with the ALPN token 'h2' (the 102 Switching

Re: TestSuite Docs (was Re: [VOTE] Release Apache httpd 2.4.21 as GA)

On 06/17/2016 08:25 AM, Jacob Perkins wrote: I’d love to be able to quickly spin up a new RPM on our Apache & PHP distribution and let automated tests slam it. Right now it’s sort of a manual process. A lot of what I’ve seen as far as a ‘how-to’ on setting up Apache Test is something like ‘cpan

Re: svn commit: r1732328 - in /httpd/httpd/trunk/modules/http2: h2_mplx.c h2_proxy_session.c h2_proxy_session.h h2_util.c h2_util.h mod_proxy_http2.c

On 02/25/2016 08:19 AM, ic...@apache.org wrote: > --- httpd/httpd/trunk/modules/http2/h2_mplx.c (original) > +++ httpd/httpd/trunk/modules/http2/h2_mplx.c Thu Feb 25 16:19:18 2016 > @@ -17,7 +17,6 @@ > #include > #include > > -#include > #include > #include > #include FYI: with this

Re: state of h2 (long)

On Mon, Feb 29, 2016 at 9:35 AM, William A Rowe Jr wrote: > On Sun, Feb 28, 2016 at 1:37 PM, Gregg Smith wrote: >> >> Hi Stefan, >> >> I've had a real lack of time lately to do much on trunk's mod_http2 on the >> windows side. The new mod_proxy_http2 requires

Re: mod_status, server, protocol

Stefan, (I'm coming at this from more of a user's perspective than a code reviewer's.) On 01/20/2016 08:26 AM, Stefan Eissing wrote: - mod_status introduces a new columne 'Protocol' for displaying the connection protocol used. I originally wondered at the purpose of the new Protocol

[PATCH 58926] Minor improvements to apxs

Hi all, I posted a four-patch set for apxs -- two functionality changes, and two cosmetic/refactoring changes -- last week after a quick conversation with Eric Covener on IRC. The motivation is primarily to improve (or disable) the auto-detection of module names during installation when the

Re: state of h2 (long)

On Mon, Feb 29, 2016 at 1:55 PM, Jacob Champion <champio...@gmail.com> wrote: > I'm only just figuring out how to actually test the proxy module at > runtime, though, so... caveat emptor. FWIW, with that patchset, I was able to get an h2c (plaintext) proxy working with the nghttp2.org

Re: state of h2 (long)

On Tue, Mar 1, 2016 at 11:08 AM, Jacob Champion <champio...@gmail.com> wrote: > I still don't have my OpenSSL build process for Windows down enough to > test out an h2 proxy, but that'll be my next trick. Looks like an HTTP/1.1 -> h2 proxy works for me as well on Windows, once I go

Re: Feedback needed: suexec different-owner patch

On 03/30/2016 01:49 PM, Stefan Fritsch wrote: > You are doing the configuration parsing in httpd, and then pass the > allowed uid/group to suexec as command line arguments. > > Sorry, but that is not a good approach. You must assume that a local > attacker calls suexec directly and passes

Re: Need hints from those building mod_http2 and mod_proxy_http2 on Windows

On 03/22/2016 03:11 PM, Jeff Trawick wrote: > What version of nghttp2 are you using? > Are you using the cmake build for httpd? I'm not currently in Windows to be able to check for sure, but I *believe* I'm running nghttp2 1.8.0. > FWIW I just found that I needed nghttp2 >= 1.4.0 on Windows to

Re: 2.4.20 Change dsp: Win32-specific build files.

On 03/24/2016 06:05 AM, William A Rowe Jr wrote: > I observed the note below in 2010 when that comment was first made (I > cribbed that comment from 2.2.x checkin). So I now wonder if that note > was based on an Express edition perhaps? Or on an early release - and > MS later added or fixed the

Re: [PATCH] Add "FreeListen" to support IP_FREEBIND

On 03/08/2016 10:47 AM, Tim Bannister wrote: >> On 8 Mar 2016, at 18:13, William A Rowe Jr wrote: >> If a websocket implementation is properly stacked on top of the >> core, there is no need for special-casing this interaction. It >> will be able to speak over http or https,

Re: Feedback needed: suexec different-owner patch

On 04/02/2016 12:56 PM, Stefan Fritsch wrote: > If suexec allowed to suid to a user different than the owner of a > script, on that server it would allow any local user to execute any > script as any other user. Even if suexec checked that the script is > owned by a special "trusted" user, it

[PATCH 59376] Provide an option to dump included configuration paths

Hi all, I've posted a patch [1] that allows the server to dump the path to every configuration file as it is included. The goal is to allow httpd newbies, server admins inheriting legacy configurations, and forgetful developers to see where their configurations are coming from at a glance. Eric

[PATCH 59618] mod_proxy_fcgi: SCRIPT_FILENAME has bogus "proxy:fcgi" prefix

Hi all, I was trying to test fcgiwrap (a general-purpose FCGI daemon) with mod_proxy_fcgi, and found that the SCRIPT_FILENAME passed to the daemon isn't actually a file path. Instead, it ends up looking something like this: proxy:fcgi://localhost:4000/usr/local/apache2/cgi-bin/test-cgi

Re: [PATCH] mod_http2, mod_proxy_http2: fix CMake support

On 05/12/2016 07:31 AM, Evgeny Kotkov wrote: @@ -451,11 +452,11 @@ SET(mod_proxy_wstunnel_extra_libsmod_proxy) SET(mod_proxy_http2_requires NGHTTP2_FOUND) SET(mod_proxy_http2_extra_defines ssize_t=long) -SET(mod_proxy_http2_extra_libs

Re: RFC 7230..7235 Parsing Conformance?

On 05/17/2016 11:31 AM, William A Rowe Jr wrote: > One of the more significant is the change to token, > https://tools.ietf.org/html/rfc2616#section-2.2 > > token = 1* > > > vs https://tools.ietf.org/html/rfc7230#section-3.2.6 > > token = 1*tchar > > tchar = "!" /

Re: RFC 7230..7235 Parsing Conformance?

On 05/17/2016 02:53 PM, William A Rowe Jr wrote: > (Note that HT is a CTL, right, so it appears to be doubly excluded, no?) > CHAR is US-ASCII 0-127. I noticed that too... It seems odd, but it's water under the bridge now, I guess. > The characters missing above from tchar are '"', '(', ')',

Re: "Upgrade: h2" header for HTTP/1.1 via TLS (Bug 59311)

On 04/19/2016 08:47 AM, William A Rowe Jr wrote: > I agree with your analysis, "h2" is not an upgrade candidate. > > "h2c" is an upgrade candidate. Is an h2c upgrade allowed over an HTTP/1.1+TLS connection? 7540 seems to hint that it's not ("The 'h2c' string is reserved from the ALPN

Re: svn commit: r1750953 - /httpd/httpd/trunk/server/util_script.c

On 07/22/2016 10:49 AM, William A Rowe Jr wrote: I'm -1 for interpretating invalid values. By "invalid" do you mean any string that doesn't comply with 723x's Last-Modified definition? Even if the only non-compliance is the use of a non-GMT timezone? I'm not personally a fan of all the

Re: svn commit: r1750953 - /httpd/httpd/trunk/server/util_script.c

On 07/22/2016 12:30 PM, William A Rowe Jr wrote: Yes, I mean anything that doesn't fit one of the *three* allowable formats. Nothing is allowed except for GMT. Agreed, only GMT is allowed on the wire. I still believe it's potentially useful, and not unsafe, to transform a non-GMT timestamp

Re: svn commit: r1750953 - /httpd/httpd/trunk/server/util_script.c

On 07/22/2016 01:38 PM, William A Rowe Jr wrote: RFC 7231 § 7.1.1 RFC 7232 § 2.2 Okay, at least we're looking at the same sections then. But I'm not finding support for your statement that we must replace completely unintelligible Last-Modified values with current timestamps. The closest I

Re: svn commit: r1750953 - /httpd/httpd/trunk/server/util_script.c

On 08/01/2016 12:38 PM, William A Rowe Jr wrote: I'll review the rest of your comments shortly, but you might want to review https://tools.ietf.org/html/rfc3875 before claiming CGI isn't an HTTP input :-) I suspect we're talking past each other at this point. I'm aware of 3875 (though I don't

Re: svn commit: r1750953 - /httpd/httpd/trunk/server/util_script.c

All right, getting back to this after a week off. I've tried to combine feedback as best I can into one message. Bill, you wrote: I'm perfectly happy to translate such values to GMT for non-HTTP inputs, per spec. If we are going to do so for HTTP inputs, loudly scolding the errant developer

Re: svn commit: r1754732 - /httpd/httpd/trunk/modules/proxy/mod_proxy_fcgi.c

To follow up on an IRC comment: I like performance improvements, but this is code that we've identified a large number of bugs/misfeatures in recently, and I think there are plans for further changes soon. Performance improvements tend to fragment things and make later refactoring difficult,

Re: svn commit: r1754548 - /httpd/httpd/trunk/server/protocol.c

On 07/31/2016 09:18 AM, William A Rowe Jr wrote: So all the trailing SP/HTAB are part of obs-fold IMHO. Should we replace all of them (plus the CRLF) with a single SP or with as many SP? Hmmm... Good point. Advancing over them in our HTTP_STRICT mode seems best, if we have a consensus on this.

Re: svn commit: r1754548 - /httpd/httpd/trunk/server/protocol.c

On 08/03/2016 11:53 AM, Roy T. Fielding wrote: Replacing each byte with a separate space (as opposed to condensing into a single space) *might* help prevent adversaries from playing games with header length checks in more complicated/layered systems. That's probably a stretch though. And if we

Re: svn commit: r1754548 - /httpd/httpd/trunk/server/protocol.c

On 08/03/2016 12:05 PM, Jacob Champion wrote: Right, I was just wondering out loud if condensing into a single space could give anyone the chance to defeat a header length check in a multi-layered system. It's admittedly a pretty "tinfoil hat" concern. Never mind. It would need to be

Re: svn commit: r1755098 - in /httpd/httpd/trunk: docs/log-message-tags/next-number server/protocol.c

On 08/03/2016 09:46 AM, wr...@apache.org wrote: Modified: httpd/httpd/trunk/server/protocol.c URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/server/protocol.c?rev=1755098=1755097=1755098=diff == ---

Re: svn commit: r1754548 - /httpd/httpd/trunk/server/protocol.c

On 08/03/2016 12:05 PM, Jacob Champion wrote: So if there is an HTAB directly *before* the obs-fold CRLF, we should not try to replace with a SP? Ad never mind here; looks like we already strip trailing OWS from the end of the line before the fold. That'll teach me to theorycraft before

Re: mod_proxy_fcgi, 304 responses and bogus error messages

On 07/11/2016 08:53 AM, Luca Toscano wrote: I am looking for some feedback about the patch proposed to figure out if I am on the right track or not. Does it make sense to read all the data returned by a FCGI backend even on error conditions to avoid subsequent spurious reads or is there a

Some Windows CMake fixes in trunk

For those of you using the CMakeLists on Windows, there are now a few bugfixes in trunk. If you have any spare time to make sure that they function properly in your workflow, that'd be much appreciated. Thanks! --Jacob

Re: svn commit: r1751970 - /httpd/httpd/trunk/modules/proxy/mod_proxy_fcgi.c

On 07/08/2016 02:49 PM, cove...@apache.org wrote: Modified: httpd/httpd/trunk/modules/proxy/mod_proxy_fcgi.c URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/proxy/mod_proxy_fcgi.c?rev=1751970=1751969=1751970=diff

2.4.23 broke an FCGI corner case (Re: [Bug 59815])

On 07/07/2016 05:11 AM, bugzi...@apache.org wrote: https://bz.apache.org/bugzilla/show_bug.cgi?id=59815 covener and I have been trading comments on IRC about this one. The summary so far is that our latest release broke a use case where all of the following are true: - FCGI requests are

Re: svn commit: r1754548 - /httpd/httpd/trunk/server/protocol.c

On 08/04/2016 01:11 PM, William A Rowe Jr wrote: At our kindest, we would like to let people keep upgrading on the 2.2 or 2.4 branches of httpd for other fixes, without breaking their deployments. I'm 100% in favor of recognizing-and-rejecting (and terminating the connection) for any obs-fold

Re: 2.4.23 broke an FCGI corner case (Re: [Bug 59815])

On 07/08/2016 01:21 PM, Jacob Champion wrote: The root cause appears to be (at least to me) that the proxy URL canonicalization step does not run when a per-directory rewrite is used. Instead, mod_rewrite simply hardcodes r->filename to include the query string. With a server-context rewr

Re: svn commit: r1750953 - /httpd/httpd/trunk/server/util_script.c

On 08/01/2016 01:35 PM, William A Rowe Jr wrote: > I do like your argument that we should do as little transformation > as possible, in order to facilitate moving CGI apps between > environments. Implementation differences are nasty for everyone. But > I'm not convinced that ship hasn't sailed;

Re: 2.4.24 soon?

On 08/02/2016 11:12 AM, William A Rowe Jr wrote: One additional thought... On 2.2 and 2.4 I see this change as entirely opt-in, no disruption to a user performing a subversion upgrade. On 2.6/3.0 I'd want us to seriously consider changing the out-of-the-box default to strict parsing. +1. (I

Re: svn commit: r1750953 - /httpd/httpd/trunk/server/util_script.c

001 From: Jacob Champion <champio...@gmail.com> Date: Thu, 21 Jul 2016 14:56:55 -0700 Subject: [PATCH] Add Last-Modified header replacement tests Per the long conversation culminating in https://lists.apache.org/thread.html/909bb1b18b723ed0127b062d0f4d18779d2c7a2acddcbd5

Re: svn commit: r1756556 - /httpd/httpd/branches/2.4.x/STATUS

On 08/16/2016 03:29 PM, yla...@apache.org wrote: *) autoconf: minor cleanup and removal of some dead code. trunk patch: http://svn.apache.org/r1753315 http://svn.apache.org/r1753316 +1: jchampion + ylavic: some conflicts with r1753315 in 2.4.x's

Re: Autobuild Progress (was Re: Automated tests)

On 01/30/2017 12:02 PM, Jacob Champion wrote: - run per-commit incremental builds - run nightly clean builds These two are implemented. Every commit you make to trunk (well, group of commits, within fifteen seconds of each other) is run through an incremental build, which takes about ten

Re: httpd 2.4.25, mpm_event, ssl: segfaults

On 02/02/2017 03:05 PM, Yann Ylavic wrote: Hmm, Linux raises SIGBUS if an mmap is used after the underlying file has been truncated (see [1]). See also https://bz.apache.org/bugzilla/show_bug.cgi?id=46688 . Niklas, just to clarify: you're not willfully truncating large files as they're being

Re: httpd 2.4.25, mpm_event, ssl: segfaults

On 02/02/2017 03:05 PM, Yann Ylavic wrote: Couldn't htcacheclean or alike do something like this? "EnableMMAP off" could definitely help here. (Didn't mean to ignore this part of your email, but I don't have much experience with htcacheclean yet so I can't really comment...) --Jacob

Re: httpd 2.4.25, mpm_event, ssl: segfaults

On 02/02/2017 02:04 AM, Yann Ylavic wrote: Hi Niklas, On Wed, Feb 1, 2017 at 7:02 PM, Niklas Edmundsson wrote: We've started to see spurious segfaults with httpd 2.4.25, mpm_event, ssl on Ubuntu 14.04LTS. Not frequent, but none the less happening. #4 ssl_io_filter_output

  1   2   3   4   >