Re: [VOTE] Switch read/write repository from Subversion to Git

> On May 4, 2023, at 1:34 AM, Ruediger Pluem wrote: > > [X]: Move the read/write repository from Subversion to Git and leverage the > features of Github (for now Actions and PR). I trust subversion more as a vcs, but that is outweighed by the convenience of Github's PR and issue management.

Re: [VOTE] [VOTE] Release httpd-2.4.56-rc1 as httpd-2.4.56

On Mar 10, 2023, at 8:56 AM, Yann Ylavic wrote: > On Fri, Mar 10, 2023 at 4:34 PM Eric Covener wrote: >> >> Saw another report on users@ >> >> Any thoughts on something like this to just allow spaces? >> http://people.apache.org/~covener/patches/rewrite-lax.diff > > What about: > > Index:

fixed autolinks from cve process

FYI, I made some minor changes to the post-release description on httpd-site and within 2.4.x/CHANGES for CVE-2023-2569 The form we use for editing the CVE json info has a feature for autolinking anything that looks like a URL reference. Unfortunately, it's buggy and cannot be turned off. When

Re: [VOTE] [VOTE] Release httpd-2.4.56-rc1 as httpd-2.4.56

idate tarball httpd-2.4.56-rc1 as 2.4.56: > [X] +1: It's not just good, it's good enough! Verified sigs, compiled and installed locally (Macbook Pro M1, macos Ventura 13.2.1), and tested around the relevant changes. Everything looks good. +1 for release. Roy T. Fielding

Re: svn commit: r1906618 - /httpd/httpd/branches/2.2.x/docs/manual/rewrite/intro.xml

I am pretty sure that this change makes the example incorrect. That regex is not supposed to match "/foo/" (even if one might want to do that for directory examples, this particular example is not about directories). /foo is the whole path. If a directory example is desired, perhaps a new

Re: svn commit: r1904269 - in /httpd/httpd/trunk: changes-entries/ docs/manual/mod/ modules/http2/ test/modules/http2/

> On Oct 19, 2022, at 2:28 AM, Stefan Eissing via dev > wrote: >> Am 18.10.2022 um 21:20 schrieb Roy T. Fielding : >> >>> On Oct 6, 2022, at 2:17 AM, Stefan Eissing via dev >>> wrote: >>> >>>> Am 05.10.2022 um 19:34 schrieb Stefan Eiss

Re: svn commit: r1904269 - in /httpd/httpd/trunk: changes-entries/ docs/manual/mod/ modules/http2/ test/modules/http2/

> On Oct 19, 2022, at 4:50 AM, Ruediger Pluem wrote: > > > > On 10/19/22 11:28 AM, Stefan Eissing via dev wrote: >> >> >>> Am 18.10.2022 um 21:20 schrieb Roy T. Fielding : >>> >>>> On Oct 6, 2022, at 2:17 AM, Stefan Eissing via dev

Re: svn commit: r1904269 - in /httpd/httpd/trunk: changes-entries/ docs/manual/mod/ modules/http2/ test/modules/http2/

> On Oct 6, 2022, at 2:17 AM, Stefan Eissing via dev > wrote: > >> Am 05.10.2022 um 19:34 schrieb Stefan Eissing via dev : >> >> >> >>> Am 05.10.2022 um 18:48 schrieb Eric Covener : >>> >>> On Wed, Oct 5, 2022 at 12:44 PM Roy T.

Re: svn commit: r1904269 - in /httpd/httpd/trunk: changes-entries/ docs/manual/mod/ modules/http2/ test/modules/http2/

> On Sep 26, 2022, at 5:29 AM, ic...@apache.org wrote: > > Author: icing > Date: Mon Sep 26 12:29:47 2022 > New Revision: 1904269 > > URL: http://svn.apache.org/viewvc?rev=1904269=rev > Log: > *) mod_http2: new directive "H2HeaderStrictness" to control the compliance > level of header

Re: backports

> On Mar 4, 2022, at 6:17 AM, Eric Covener wrote: > > On Fri, Mar 4, 2022 at 9:05 AM Jim Jagielski wrote: >> >> A question: Would it be easier for all this if we moved to being Github >> canon? > > I think it is much more straightforward. The original work, reviews > and travis results are

Re: svn commit: r1897872 - in /httpd/httpd/trunk: changes-entries/http2_request_scheme.txt modules/http2/h2_stream.c test/modules/http2/test_003_get.py

> On Feb 9, 2022, at 1:28 AM, Stefan Eissing wrote: >> Am 09.02.2022 um 10:15 schrieb Ruediger Pluem : >> On 2/8/22 7:10 PM, Roy T. Fielding wrote: >>> As noted in >>> >>> https://github.com/icing/mod_h2/issues/230#issuecomment-1032905432 >>>

Re: svn commit: r1897872 - in /httpd/httpd/trunk: changes-entries/http2_request_scheme.txt modules/http2/h2_stream.c test/modules/http2/test_003_get.py

As noted in https://github.com/icing/mod_h2/issues/230#issuecomment-1032905432 This doesn't look right to me. I think what you want is to verify that https is in a secured connection. This should have no effect on other schemes, and certainly not require all schemes to be http or https.

Re: http and http/1.x separation

> On Jan 24, 2022, at 6:53 AM, Stefan Eissing wrote: > > > >> Am 24.01.2022 um 15:40 schrieb Yann Ylavic > >: >> >> On Mon, Jan 24, 2022 at 3:28 PM Stefan Eissing > > wrote: >>> >>> FYI: I am busy hacking away at the separation between

Re: svn commit: r1895955 - in /httpd/httpd/branches/2.4.x: ./ CHANGES include/ap_mmn.h include/http_protocol.h modules/http/http_request.c modules/http2/h2_request.c modules/proxy/mod_proxy.c modules/

> On Dec 14, 2021, at 2:22 PM, Yann Ylavic wrote: > > On Tue, Dec 14, 2021 at 6:26 PM Roy T. Fielding wrote: >> >> This is a little confusing. It looks from the comment and code like the >> change is restricting the request target that can be sent through a pro

Re: svn commit: r1895955 - in /httpd/httpd/branches/2.4.x: ./ CHANGES include/ap_mmn.h include/http_protocol.h modules/http/http_request.c modules/http2/h2_request.c modules/proxy/mod_proxy.c modules/

) because that is a feature of HTTP. Is that what was intended? Roy > On Dec 14, 2021, at 9:10 AM, Roy T. Fielding wrote: > > I am pretty sure that this isn't correct, or at least seems like overkill. > We should definitely block unix: from being forwarded, but why would > we want

Re: svn commit: r1895955 - in /httpd/httpd/branches/2.4.x: ./ CHANGES include/ap_mmn.h include/http_protocol.h modules/http/http_request.c modules/http2/h2_request.c modules/proxy/mod_proxy.c modules/

I am pretty sure that this isn't correct, or at least seems like overkill. We should definitely block unix: from being forwarded, but why would we want to block things like a urn: resolver? To be clear, I'd rather remove all proxy functionality from httpd than suggest to the world that http(s)

Re: disallow HTTP 0.9 by default?

> On Jul 22, 2021, at 12:29 AM, Stefan Eissing > wrote: >> Am 21.07.2021 um 22:04 schrieb Eric Covener : >> >> I was chasing an unrelated thread about close_notify alerts and >> reminded me -- is it time to change the default for >> HttpProtocolOptions from Allow0.9 to Require1.0? >> >> As the

where do we want to send website bot notices?

I was about to update the site config so that it wouldn't send notices to dev, but I don't know whether they should instead go to cvs, docs, or a new list (like notices at httpd). Any opinions? Roy

Re: Question about APR trunk and httpd ldap modules

> On May 28, 2021, at 9:59 AM, William A Rowe Jr wrote: > > AIUI, as he remains a PMC member, the veto remains binding per Roy's > conclusion, whether it was made 9 weeks ago or 9 years ago. I do not, so just > sharing historical pointers for those raising questions, no opinion remaining > of

Re: [VOTE] Release httpd-2.4.47

On Apr 29, 2021, at 5:18 AM, Ruediger Pluem wrote: > On 4/29/21 2:09 PM, Eric Covener wrote: >> On Thu, Apr 29, 2021 at 7:40 AM Ivan Zhakov wrote: >>> I have noticed regression in ETag response header handling in httpd 2.4.47: >>> ETag response header is not set for HTTP 304 responses. While

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

> On Dec 16, 2020, at 2:52 AM, Graham Leggett wrote: > > On 12 Dec 2020, at 01:59, Roy T. Fielding <mailto:field...@gbiv.com>> wrote: > >> That is too many questions. The purpose of the cache requirement is so that >> the cache >> does not delive

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

> On Dec 11, 2020, at 6:28 AM, Ruediger Pluem wrote: > On 12/11/20 1:13 PM, Yann Ylavic wrote: >> On Fri, Dec 11, 2020 at 12:49 PM Graham Leggett wrote: >>> >>> On 10 Dec 2020, at 18:04, yla...@apache.org wrote: >>> >>> Author: ylavic >>> Date: Thu Dec 10 16:04:34 2020 >>> New Revision:

Re: Reject HTTP protocols >= 2.0 in ap_parse_request_line?

> On Jun 18, 2020, at 9:03 AM, Stefan Eissing > wrote: >> Am 18.06.2020 um 16:51 schrieb William A Rowe Jr : >> >> >>>>>> On 6/18/20 12:09 AM, Roy T. Fielding wrote: >>>>>>>> On Jun 8, 2020, at 12:56 AM, Ruediger Pluem

Re: Reject HTTP protocols >= 2.0 in ap_parse_request_line?

> On Jun 8, 2020, at 12:56 AM, Ruediger Pluem wrote: > > I came across the question if we should not reject HTTP protocols >= 2.0 in > the request line when we parse it > in ap_parse_request_line. > This does not affect mod_http2 if loaded as HTTP/2.0 connections itself are > not parsed via

Re: Migrate to git?

> On Oct 5, 2019, at 1:09 PM, Jim Jagielski wrote: > > Various PMCs have made their default/de-facto SCM git and have seen an > increase in contributions and contributors... > > Is this something the httpd project should consider? Especially w/ the > foundation officially supporting Github,

Re: [PATCH] Return HTTP 431 (Request Header Fields Too Large) for requests with large headers

> On Aug 27, 2019, at 5:19 AM, Ivan Zhakov wrote: > > On Wed, 14 Mar 2018 at 10:05, Ivan Zhakov wrote: >> >> Hi, >> >> Please find patch that changes HTTPD to return HTTP 431 (Request >> Header Fields Too Large) for requests with large headers. This status >> code is defined by RFC 6585 [1].

Re: keep-alive and vary in 304 responses

> On Apr 10, 2019, at 3:10 AM, Stefan Eissing > wrote: > > >> Am 09.04.2019 um 18:48 schrieb Roy T. Fielding : >> >>> >>> 2. Validation responses lose the "Vary" header from the unconditional >>> response. This happens on resour

Re: keep-alive and vary in 304 responses

> On Apr 9, 2019, at 3:30 AM, Stefan Eissing > wrote: > > I just did some tests with https://redbot.org/ (the site tester by Mark > Nottingham) against our server and it notifies of 2 things: > > 1. The "Keep-Alive" header is deprecated. I tried to "Header unset > Keep-Alive" but that has no

Re: Host header checking too strict?

> On Jun 25, 2018, at 8:57 AM, William A Rowe Jr wrote: > > On Mon, Jun 25, 2018 at 5:31 AM, Joe Orton > wrote: > On Fri, Jun 22, 2018 at 05:21:08PM -0400, Eric Covener wrote: > > After CVE-2016-8743 we only accept hostnames that are valid in DNS, > > which notably

Re: The Case for Managed Domains

> On Feb 9, 2018, at 12:06 PM, Stefan Eissing > wrote: >> Am 09.02.2018 um 16:12 schrieb Daniel : >> >> I'm getting lost. >> >> What would VirtualServer tag mean exactly? >> >> Thanks in advance and apologies for my slowness :) > > The

Re: svn commit: r1764961 - in /httpd/httpd/trunk: docs/manual/mod/core.xml modules/http/http_filters.c server/core.c server/gen_test_char.c server/protocol.c server/util.c

> On Oct 15, 2016, at 2:10 AM, William A Rowe Jr <wr...@rowe-clan.net> wrote: > > On Sat, Oct 15, 2016 at 3:54 AM, William A Rowe Jr <wr...@rowe-clan.net > <mailto:wr...@rowe-clan.net>> wrote: > On Fri, Oct 14, 2016 at 4:44 PM, Roy T. Fielding <field...@g

Re: svn commit: r1764961 - in /httpd/httpd/trunk: docs/manual/mod/core.xml modules/http/http_filters.c server/core.c server/gen_test_char.c server/protocol.c server/util.c

Right, though several people have requested it now as errata. Seems likely to be in the final update for STD. Roy > On Oct 14, 2016, at 2:16 PM, William A Rowe Jr wrote: > >> On Fri, Oct 14, 2016 at 3:48 PM, wrote: >> Author: wrowe >> Date: Fri Oct

Re: StrictURI in the wild [Was: Backporting HttpProtocolOptions survey]

> On Sep 14, 2016, at 6:28 AM, William A Rowe Jr wrote: > > On Tue, Sep 13, 2016 at 5:07 PM, Jacob Champion > wrote: > On 09/13/2016 12:25 PM, Jacob Champion wrote: > What is this? Is this the newest "there are a bunch of

Re: svn commit: r1756531 - /httpd/httpd/trunk/modules/proxy/proxy_util.c

> On Aug 16, 2016, at 9:51 AM, Eric Covener <cove...@gmail.com> wrote: > > On Tue, Aug 16, 2016 at 12:26 PM, Roy T. Fielding <field...@gbiv.com> wrote: >> It used to be that we always log INFO because we only use it for noting >> configuration details. Has t

Re: svn commit: r1756531 - /httpd/httpd/trunk/modules/proxy/proxy_util.c

> On Aug 16, 2016, at 9:21 AM, yla...@apache.org wrote: > > Author: ylavic > Date: Tue Aug 16 16:21:13 2016 > New Revision: 1756531 > > URL: http://svn.apache.org/viewvc?rev=1756531=rev > Log: > Follow up to r1750392: reduce AH03408 level to INFO as suggested by wrowe/jim. It used to be that we

Re: HTTP/1.1 strict ruleset

> On Aug 11, 2016, at 9:59 AM, William A Rowe Jr wrote: > > On Thu, Aug 11, 2016 at 11:54 AM, Eric Covener > wrote: > On Thu, Aug 11, 2016 at 12:44 PM, William A Rowe Jr >

Re: HTTP/1.1 strict ruleset

> On Aug 4, 2016, at 3:02 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote: > > On Thu, Aug 4, 2016 at 3:46 PM, Roy T. Fielding <field...@gbiv.com > <mailto:field...@gbiv.com>> wrote: > > On Aug 3, 2016, at 4:33 PM, William A Rowe Jr <wr...@rowe-clan.net

Re: HTTP/1.1 strict ruleset

> On Aug 3, 2016, at 4:33 PM, William A Rowe Jr wrote: > > So it seems pretty absurd we are coming back to this over > three years later, but is there any reason to preserve pre-RFC 2068 > behaviors? I appreciate that Stefan was trying to avoid harming > existing deployment

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

> On Aug 3, 2016, at 2:28 PM, William A Rowe Jr wrote: > > So AIUI, the leading SP / TAB whitespace in a field is a no-op (usually > represented by a single space by convention), and trailing whitespace > in the field value is a no-op, all leading tabs/spaces (beyond one

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

> On Aug 3, 2016, at 11:44 AM, Jacob Champion wrote: > > 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...

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

> On Apr 20, 2016, at 4:29 AM, Stefan Eissing > wrote: > >> >> Am 20.04.2016 um 13:16 schrieb Yann Ylavic : >> >> On Wed, Apr 20, 2016 at 1:09 PM, Yann Ylavic wrote: >>> On Wed, Apr 20, 2016 at 11:25 AM, Stefan Eissing

Fwd: RFC 7804 on Salted Challenge Response HTTP Authentication Mechanism

For folks looking for a new feature to develop, Roy > Begin forwarded message: > > From: rfc-edi...@rfc-editor.org > Subject: RFC 7804 on Salted Challenge Response HTTP Authentication Mechanism > Date: March 9, 2016 at 11:01:55 AM PST > To: ietf-annou...@ietf.org, rfc-d...@rfc-editor.org >

where to put update_mime_types.pl?

I have a perl script (see below) for updating the mime.types file with the latest registered IANA media types. I would like to add it to our version control, but I am unsure whether to place it in httpd/trunk/support/ or in httpd/docs-build/trunk/ I guess it depends on whether we want to

Re: svn commit: r1725349 - /httpd/httpd/trunk/docs/manual/env.xml

I don't understand this comment. RFC7230 doesn't recommend sending HTTP/1.0. It certainly allows it as a workaround for a broken client, but force-response-1.0 is not recommended for general use. Roy > On Jan 18, 2016, at 1:14 PM, cove...@apache.org wrote: > > Author: covener > Date: Mon

Re: Upgrade Summary

> On Dec 8, 2015, at 2:07 AM, Stefan Eissing > wrote: > > Trying to summarize the status of the discussion and where the issues are > with the current Upgrade implementation. > > Clarified: > A. any 100 must be sent out *before* a 101 response > B. request bodies

Re: svn commit: r1710723 - in /httpd/httpd/trunk: CHANGES modules/cache/cache_util.h

> On Oct 26, 2015, at 11:45 PM, jaillet...@apache.org wrote: > > Author: jailletc36 > Date: Tue Oct 27 06:45:03 2015 > New Revision: 1710723 > > URL: http://svn.apache.org/viewvc?rev=1710723=rev > Log: > RFC2616 defines #rules as: > #rule > A construct "#" is defined, similar to "*", for

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

> On Oct 26, 2015, at 10:33 AM, Jacob Champion wrote: > > 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

Re: svn commit: r1708593 - in /httpd/httpd/trunk: docs/manual/mod/mod_http2.xml modules/http2/h2_config.c modules/http2/h2_config.h modules/http2/h2_conn.c modules/http2/h2_h2.c modules/http2/h2_h2.h

Can you please choose a more specific directive name? Like "LimitTLSunderH2". We don't have switches for RFC compliance. We do have switches for stupid WG political positions that contradict common sense and are not applicable to non-Internet deployments. Roy > On Oct 14, 2015, at 5:10

Re: HTTP_MISDIRECTED_REQUEST

On Aug 26, 2015, at 3:15 PM, William A Rowe Jr wr...@rowe-clan.net mailto:wr...@rowe-clan.net wrote: Should this exception have a protocol version guard for HTTP/2.0 requests, and leave the response as HTTP_BAD_REQUEST for HTTP/1.1 and earlier? @@ -203,6 +204,9 @@

Re: TWS ; LWS permitted by RFC 7230 4.1.1? Apparently, no.

On Jun 15, 2015, at 9:33 AM, William A Rowe Jr wr...@rowe-clan.net wrote: Reviewing the spec, I cannot find where Sambar server is permitted to insert whitespace. I further reviewed the ABNF appendix, and it does not appear there, either. Right, this was a deliberate decision to reduce

Re: RFC 7540 (HTTP/2) wrt reusable connections and SNI

On Jun 9, 2015, at 3:42 AM, Yann Ylavic ylavic@gmail.com wrote: It just needed to get out :) But I agree that since we are to implement the RFC, we must comply, and find a way to still comply with HTTP/1. Both checks on SNI and renegotiation occur in the post_read_request hook, so we

Re: ALPN patch comments

On Jun 4, 2015, at 9:19 AM, Stefan Eissing stefan.eiss...@greenbytes.de wrote: I think we need to clarify some things: 1. ALPN is initiated by the client. When a client does not send ALPN as part of client helo, the SSL alpn callbacks are not invoked and the server does not send any

Re: svn commit: r1492395 - in /httpd/httpd/trunk: CHANGES modules/aaa/mod_auth_digest.c

On Jun 14, 2013, at 2:16 PM, Stefan Fritsch wrote: On Thursday 13 June 2013, Roy T. Fielding wrote: On Jun 12, 2013, at 12:34 PM, s...@apache.org wrote: Author: sf Date: Wed Jun 12 19:34:19 2013 New Revision: 1492395 URL: http://svn.apache.org/r1492395 Log: Actually use the secret when

Re: svn commit: r1492395 - in /httpd/httpd/trunk: CHANGES modules/aaa/mod_auth_digest.c

On Jun 12, 2013, at 12:34 PM, s...@apache.org wrote: Author: sf Date: Wed Jun 12 19:34:19 2013 New Revision: 1492395 URL: http://svn.apache.org/r1492395 Log: Actually use the secret when generating nonces. This change may cause problems if used with round robin load balancers. Before

Re: RFC: Handling abnormally large chunk sizes

On May 14, 2013, at 8:58 AM, Graham Leggett wrote: 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

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

On May 8, 2013, at 1:11 AM, Ruediger Pluem wrote: Graham Leggett wrote: On 08 May 2013, at 9:47 AM, Ruediger Pluem rpl...@apache.org 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

Re: mod_cache with Cache-Control no-cache= or private=

On Mar 13, 2013, at 10:20 AM, Graham Leggett wrote: On 11 Mar 2013, at 12:50 PM, Yann Ylavic ylavic@gmail.com 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.

Re: [Vote] Overhaul modules.apache.org

+1 Roy

Re: [VOTE] accept mod_macro as standard module in httpd

+1 Roy

Re: mod_macro contributors?

On Dec 30, 2012, at 5:19 PM, Eric Covener wrote: On Mon, Dec 24, 2012 at 1:42 AM, fab...@apache.org wrote: Thanks Fabien. I am striking out on a valid e-mail for Dirk. Do you recall if he even sent in a patch, and if so the size/scope? It was not a patch. It was a bug report about the

Re: svn commit: r1426877 - in /httpd/httpd/trunk: CHANGES include/ap_mmn.h include/http_core.h include/httpd.h modules/http/http_filters.c server/core.c server/protocol.c server/util.c server/vhost.c

Hi Stefan, Thanks for this work, but I don't consider HTTP conformance to be an option. These are checks we should be making while parsing the received message, not as a separate pass, and in many cases they are required to result in a 400, 500, or 502 response. I am trying to get HTTPbis ready

Re: svn commit: r1406719 - in /httpd/httpd/trunk: CHANGES docs/log-message-tags/next-number include/http_core.h server/core.c server/protocol.c

On Nov 8, 2012, at 2:39 AM, Stefan Fritsch wrote: On Wed, 7 Nov 2012, Graham Leggett wrote: On 07 Nov 2012, at 8:12 PM, Stefan Fritsch s...@sfritsch.de wrote: Any suggestions for a syntax? Maybe: HttpProtocol 1.1# only 1.1 HttpProtocol 1.0- # 1.0 and above HttpProtocol 1.0-1.1

Re: [Bug 53219] mod_ssl should allow to disable ssl compression

On Oct 7, 2012, at 6:05 PM, Eric Covener wrote: Any opinions on the default change? AIUI current maintenance of browsers have disabled TLS compression already, because they can be driven to generate arbitrary traffic that eventually reveals httpOnly session cookies. Just disable it

Re: DNT IE10 (was svn commit: r1371878 - /httpd/httpd/trunk/docs/conf/httpd.conf.in)

On Sep 13, 2012, at 4:48 AM, Eric Covener wrote: On Sat, Aug 11, 2012 at 3:51 AM, field...@apache.org wrote: Author: fielding Date: Sat Aug 11 07:51:52 2012 New Revision: 1371878 URL: http://svn.apache.org/viewvc?rev=1371878view=rev Log: Apache does not tolerate deliberate abuse of open

Re: Ideas for an output filter for mod_lua

On Aug 23, 2012, at 2:49 PM, Nick Kew wrote: On Thu, 23 Aug 2012 22:32:20 +0100 Tim Bannister is...@jellybaby.net wrote: That's quite neat, then. I will try to make an actual implementation in Lua. The part I found difficult was the interaction with the second transfer-encoding,

Re: [VOTE] Release Apache httpd 2.4.3 as GA

signatures are good source files checked against svn license and notices in place compiles and runs on Mac OS X 10.7.4 +1 Roy

undesired modules loading

I built 2.4.3 with the options ./configure \ --prefix=$tdir \ --with-apr=$adir \ --with-apr-util=$adir \ --without-ssl \ --without-crypto \ --disable-cache \ --without-distcache \

Re: undesired modules loading

On Aug 18, 2012, at 1:45 PM, Rainer Jung wrote: Yes, before 2.4.0 we introduced exactly this difference. All modules that were build get a LoadModule line in the installed config, but most are commented out. I don't have the list of modles active by default at hand though. Ah, okay. At

Re: Time for Apache httpd 2.4.3 ??

I don't know of any issues with 308, and Julian generally knows what he is doing with regard to HTTP. In general, we should consider the IANA registry to be authoritative unless it is a known bug, which means we should support everything in

Re: TRACE still enabled by default

On Mar 21, 2012, at 5:33 AM, Jim Jagielski wrote: On Mar 20, 2012, at 3:04 PM, Stefan Fritsch wrote: On Saturday 17 March 2012, Roy T. Fielding wrote: We still enable TRACE by default. Is this useful enough to justify making every other poor sap with a security scanner have

Re: TRACE still enabled by default

On Mar 16, 2012, at 7:18 AM, Eric Covener wrote: We still enable TRACE by default. Is this useful enough to justify making every other poor sap with a security scanner have to manually turn it off? Yes. I'm hoping 2.4.x is early enough in life where flipping this wouldn't be too

Re: svn commit: r1301867 - /httpd/httpd/trunk/docs/conf/mime.types

On Mar 17, 2012, at 1:12 AM, William A. Rowe Jr. wrote: On 3/17/2012 12:59 AM, field...@apache.org wrote: Author: fielding Date: Sat Mar 17 05:59:06 2012 New Revision: 1301867 URL: http://svn.apache.org/viewvc?rev=1301867view=rev Log: new IANA media types as of 2012 Mar 16 18:55 PDT

Fwd: Working Group Last Call: httpbis p4 / p5 / p6 / p7

In case some folks want to check our compliance and fix the spec (or the code) if we aren't ... now is the time. Roy Begin forwarded message: Resent-From: ietf-http...@w3.org From: Mark Nottingham m...@mnot.net Subject: Working Group Last Call: httpbis p4 / p5 / p6 / p7 Date: March 15,

Re: Technical reasons for -1 votes (?)

On Mar 1, 2012, at 9:20 AM, William A. Rowe Jr. wrote: On 2/29/2012 6:25 PM, Roy T. Fielding wrote: On Feb 29, 2012, at 9:42 AM, William A. Rowe Jr. wrote: Let's take Roy's position on the attached vote discussion, it's relevant. These new modules are certainly additions/deletions to httpd

Re: Technical reasons for -1 votes (?)

On Mar 1, 2012, at 12:28 PM, William A. Rowe Jr. wrote: On 3/1/2012 1:58 PM, Jim Jagielski wrote: On Mar 1, 2012, at 1:25 PM, William A. Rowe Jr. wrote: On 2/29/2012 6:25 PM, Roy T. Fielding wrote: Yes, but they are modules. Hence, their mere existence in our tree is not a technical

Re: Technical reasons for -1 votes (?)

On Feb 29, 2012, at 9:42 AM, William A. Rowe Jr. wrote: On 2/29/2012 8:59 AM, André Malo wrote: On Wednesday 29 February 2012 04:11:35 William A. Rowe Jr. wrote: I withdraw this vote, reverting my position to -1, until collaboration and respect for options and insights of fellow committers

Re: Effective IP address / real IP address

On Dec 13, 2011, at 5:33 PM, Graham Leggett wrote: On 14 Dec 2011, at 12:50 AM, Graham Leggett wrote: On 12 Dec 2011, at 11:25 PM, William A. Rowe Jr. wrote: I have a frustrating update, which we need to take into consideration for the whole remote_ip-related resolution. From the httpd-ng

trunk makefile echoing modules

I am getting the following on OS X Lion: Installing configuration files /bin/sh: ,authn_file,: command not found /bin/sh: ,authn_dbm,: command not found /bin/sh: ,authn_anon,: command not found /bin/sh: ,authn_dbd,: command not found /bin/sh: ,authn_socache,: command not found /bin/sh:

Re: Who's at the Hackathon?

On Nov 7, 2011, at 9:22 AM, Sander Temme wrote: Folks, The httpd table now has: Jeff Trawick Jean-Frederic Leclere Stefan Fritsch Rainer Jung and myself Who else is at the conference? Anybody joining tomorrow? I'll be around tomorrow (at the board meeting today). …Roy

Re: svn commit: r1187992 - /httpd/httpd/trunk/modules/filters/mod_filter.c

On Oct 23, 2011, at 3:19 PM, s...@apache.org wrote: else if (r-content_type) { const char **type = provider-types; AP_DEBUG_ASSERT(type != NULL); while (*type) { -if (strcmp(*type, r-content_type) == 0) { +/* Handle

Re: svn commit: r1187986 - in /httpd/httpd/trunk/docs/manual: custom-error.xml mod/core.xml

On Oct 23, 2011, at 3:09 PM, s...@apache.org wrote: --- httpd/httpd/trunk/docs/manual/mod/core.xml (original) +++ httpd/httpd/trunk/docs/manual/mod/core.xml Sun Oct 23 22:09:34 2011 @@ -1165,6 +1165,7 @@ in case of an error/description ErrorDocument 404 /cgi-bin/bad_urls.plbr /

Re: svn commit: r1172686 - in /httpd/httpd/trunk: ./ include/ modules/cache/ modules/examples/ modules/proxy/ modules/ssl/ server/ server/mpm/event/ server/mpm/worker/

I am pretty sure that this kind of change has been vetoed numerous times in the past. What has changed? Roy On Sep 19, 2011, at 9:25 AM, s...@apache.org wrote: Author: sf Date: Mon Sep 19 16:25:42 2011 New Revision: 1172686 URL: http://svn.apache.org/viewvc?rev=1172686view=rev Log:

Re: svn commit: r1163833 - /httpd/httpd/trunk/modules/http/byterange_filter.c

On Sep 1, 2011, at 1:11 AM, Tim Bannister wrote: On Wed, Aug 31, 2011 at 6:28 PM, Roy T. Fielding wrote: On Aug 31, 2011, at 6:10 PM, William A. Rowe Jr. wrote: The presumption here is that the client requests bytes=0- to begin the transmission, and provided it sees a 206, restarting

Re: svn commit: r1163833 - /httpd/httpd/trunk/modules/http/byterange_filter.c

On Aug 31, 2011, at 2:37 PM, s...@apache.org wrote: Author: sf Date: Wed Aug 31 21:37:38 2011 New Revision: 1163833 URL: http://svn.apache.org/viewvc?rev=1163833view=rev Log: Send a 206 response for a Range: bytes=0- request, even if 200 would be more efficient. 200 is a better response

Re: svn commit: r1163833 - /httpd/httpd/trunk/modules/http/byterange_filter.c

On Aug 31, 2011, at 6:10 PM, William A. Rowe Jr. wrote: On 8/31/2011 6:06 PM, Stefan Fritsch wrote: On Wednesday 31 August 2011, Roy T. Fielding wrote: Author: sf Date: Wed Aug 31 21:37:38 2011 New Revision: 1163833 URL: http://svn.apache.org/viewvc?rev=1163833view=rev Log: Send a 206

Re: Fixing Ranges

On Aug 25, 2011, at 2:02 PM, Jim Jagielski wrote: Using stef's byterange4 test, I'm seeing: apr_brigade_length (bb=0x7feb00a23200, read_all=1, length=0x7fff6e03e8b0) at apr_brigade.c:201 201 if (bkt-length == (apr_size_t)(-1)) { apr_size_t is unsigned. That's borked. Roy

Re: DoS with mod_deflate range requests

On Aug 24, 2011, at 8:35 AM, Tim Bannister wrote: On Tue, Aug 23, 2011, Roy T. Fielding wrote: And the spec says ... When a client requests multiple ranges in one request, the server SHOULD return them in the order that they appeared in the request. My suggestion is to reject any

Re: DoS with mod_deflate range requests

On Aug 24, 2011, at 8:55 AM, Plüm, Rüdiger, VF-Group wrote: Hm. If I got it right what Roy says above about the spec sorting and merging is not an option as we need to stick to the order and number of ranges the client requested. But we can deny overlapping with a 416. We should implement

Re: DoS with mod_deflate range requests

On Aug 24, 2011, at 1:56 PM, Roy T. Fielding wrote: To be clear, I am more than willing to rewrite the part on Ranges such that the above is explicitly forbidden in HTTP. I am not sure what the WG would agree to, but I am quite certain that part of the reason we have an Apache server

Re: DoS with mod_deflate range requests

On Aug 24, 2011, at 4:39 PM, William A. Rowe Jr. wrote: On 8/24/2011 4:54 PM, Roy T. Fielding wrote: On Aug 24, 2011, at 1:56 PM, Roy T. Fielding wrote: To be clear, I am more than willing to rewrite the part on Ranges such that the above is explicitly forbidden in HTTP. I am not sure what

Re: DoS with mod_deflate range requests

On Aug 23, 2011, at 2:34 PM, William A. Rowe Jr. wrote: On 8/23/2011 4:00 PM, Greg Ames wrote: On Tue, Aug 23, 2011 at 3:32 PM, William A. Rowe Jr. wrote: I suggest we should be parsing and reassembling the list before we start the bucket logic. I propose we satisfy range

Re: [vote] mod_ldap

On Jul 12, 2011, at 8:20 AM, Joe Orton wrote: On Sun, Jul 10, 2011 at 03:34:10PM -0700, Roy T. Fielding wrote: Regardless of anyone else's opinion, the addition or deletion of a new API to our product is a technical change that can be vetoed. Likewise, the API being an incomplete abstraction

Re: [vote] mod_ldap

Regardless of anyone else's opinion, the addition or deletion of a new API to our product is a technical change that can be vetoed. Likewise, the API being an incomplete abstraction that isn't needed in httpd is a valid technical reason to veto it even if it had once been in apr-util. Other than

Re: MPM-Event, renaming MaxClients, etc.

On Jun 20, 2011, at 12:01 PM, Stefan Fritsch wrote: On Monday 20 June 2011, William A. Rowe Jr. wrote: On 6/20/2011 9:07 AM, Greg Ames wrote: On Sun, Jun 19, 2011 at 8:49 AM, Stefan Fritsch s...@sfritsch.de mailto:s...@sfritsch.de wrote: Speaking about config options, I think that

Re: MPM-Event, renaming MaxClients, etc.

On Jun 20, 2011, at 2:48 PM, William A. Rowe Jr. wrote: On 6/20/2011 4:36 PM, Stefan Fritsch wrote: On Monday 20 June 2011, Roy T. Fielding wrote: On Jun 20, 2011, at 12:01 PM, Stefan Fritsch wrote: On Monday 20 June 2011, William A. Rowe Jr. wrote: On 6/20/2011 9:07 AM, Greg Ames wrote

Re: blocking Upgrade

On Mar 29, 2011, at 11:16 PM, Greg Stein wrote: Do you have an internet draft spec for some context here? Is there a proposal for HTTP/2.0? websockets I might also argue that a directive is not the right answer here. Instead, I'd suggest that modules advertise their ability to consume

Re: blocking Upgrade

On Mar 30, 2011, at 12:32 PM, Graham Leggett wrote: On 30 Mar 2011, at 10:49 AM, Roy T. Fielding wrote: On Mar 29, 2011, at 11:16 PM, Greg Stein wrote: Do you have an internet draft spec for some context here? Is there a proposal for HTTP/2.0? websockets In theory, over and above

Re: blocking Upgrade

On Mar 30, 2011, at 4:11 PM, Graham Leggett wrote: On 30 Mar 2011, at 3:53 PM, Roy T. Fielding wrote: No, websockets is not designed to work with intermediaries. There is no standard behavior beyond opening the connection, so connections through proxies should use CONNECT. Does

blocking Upgrade

Does anyone with a working install want a quick project? We need to block the Upgrade header field by default. What this will require is a new configuration command, like AllowUpgrade None | word ... where word is any protocol name, like HTTP/2.0, waka, websocket, etc. The config command

Re: svn commit: r1070179 - in /httpd/httpd/trunk: CHANGES docs/manual/mod/mod_cache.xml modules/cache/cache_storage.c modules/cache/cache_storage.h modules/cache/mod_cache.c modules/cache/mod_cache.h

On Feb 13, 2011, at 5:03 AM, Graham Leggett wrote: On 13 Feb 2011, at 9:59 AM, Roy T. Fielding wrote: URL: http://svn.apache.org/viewvc?rev=1070179view=rev Log: mod_cache: When a request other than GET or HEAD arrives, we must invalidate existing cache entities as per RFC2616 13.10. PR

  1   2   3   4   5   6   >