Re: [RFC/PATCH] Avoid redefining apr_filepath_merge() for UNC path checks

On Fri, Jul 12, 2024 at 7:15 AM Ruediger Pluem wrote: > On 7/12/24 1:05 PM, Eric Covener wrote: > > Any concerns on this? @Ruediger Pluem ? > > I agree with all the arguments, but how do we protect 3rd party modules? > They would need to switch to ap_filepath_merge as well. Leaving the awkward r

Re: [RFC/PATCH] Avoid redefining apr_filepath_merge() for UNC path checks

On 7/12/24 1:05 PM, Eric Covener wrote: > Any concerns on this? @Ruediger Pluem ? I agree with all the arguments, but how do we protect 3rd party modules? They would need to switch to ap_filepath_merge as well. Regards Rüdiger

Re: [RFC/PATCH] Avoid redefining apr_filepath_merge() for UNC path checks

Any concerns on this? @Ruediger Pluem ? On Wed, Jul 3, 2024 at 9:29 PM Eric Covener wrote: > > On Tue, Jul 2, 2024 at 7:34 AM Evgeny Kotkov via dev > wrote: > > > > Hi all, > > > > Currently, `httpd.h` redefines the `apr_filepath_merge()` function on Win32 > > as follows: > > ``` > > #ifdef WIN3

Re: [RFC/PATCH] Avoid redefining apr_filepath_merge() for UNC path checks

On Tue, Jul 2, 2024 at 7:34 AM Evgeny Kotkov via dev wrote: > > Hi all, > > Currently, `httpd.h` redefines the `apr_filepath_merge()` function on Win32 > as follows: > ``` > #ifdef WIN32 > #define apr_filepath_merge ap_filepath_merge > #endif > ``` > > The intent behind this redefinition seems to

[RFC/PATCH] Avoid redefining apr_filepath_merge() for UNC path checks

Hi all, Currently, `httpd.h` redefines the `apr_filepath_merge()` function on Win32 as follows: ``` #ifdef WIN32 #define apr_filepath_merge ap_filepath_merge #endif ``` The intent behind this redefinition seems to be to retroactively apply the recently introduced UNC path checks to any existing

Re: [RFC] JSON logging support for httpd 2.4.x

Hi, How to proceed with #373, can someone please give some feedback? Mfg Thomas Am 8. September 2023 20:35:09 MESZ schrieb Thomas Meyer : >Hi, > >as I learned all code must go to trunk first, so I kindly ask to review my >updated patch against trunk here: > >https://github.com/apache/httpd/pull

Re: [RFC] JSON logging support for httpd 2.4.x

Hi, as I learned all code must go to trunk first, so I kindly ask to review my updated patch against trunk here: https://github.com/apache/httpd/pull/373 Once this pr is reviewed and merged I'm going to retrofit pr353 against 2.4.x with kind regards thomas Am 31. März 2023 09:04:35 MESZ schr

Re: [RFC] JSON logging support for httpd 2.4.x

Le 31/03/2023 à 09:04, Thomas Meyer a écrit : Hi, Sadly I got no feedback at all. What is the preferred way for contributions? Hi, mailing list is fine. You can also use github if it is easier for you. I also did raise a PR here with some fixes on top of this patch series: https://github

Re: [RFC] JSON logging support for httpd 2.4.x

Hi, Sadly I got no feedback at all. What is the preferred way for contributions? I also did raise a PR here with some fixes on top of this patch series: https://github.com/apache/httpd/pull/353 Mfg Thomas Am 24. März 2023 22:54:08 MEZ schrieb Thomas Meyer : > >Hi, > >please have a look at thi

[RFC] JSON logging support for httpd 2.4.x

Hi, please have a look at this preliminarily work to support JSON output in mod_log_config. It's still unfinished and has probably a lot of bugs, but this is to show the general idea of my solution. Help and feedback is most welcome. Mfg thomas

Re: RFC: Documenting changes in the CHANGES file

On 6/8/20 10:20 AM, Ruediger Pluem wrote: > >> > > Thanks for all the feedback. I try to work out something more detailed aka > patch that we can discuss then. > Done as r1879822. Happy to get some feedback. Regards Rüdiger

Re: RFC: Documenting changes in the CHANGES file

> On 1 Jun 2020, at 13:33, Graham Leggett wrote: > > On 29 May 2020, at 21:30, Ruediger Pluem wrote: > >> changes-fragments/ >>2.4.41/ >>2.4.42/ >>2.4.43/ >>2.4.44/ And a current/ as symlink? > I’m keen for a

Re: RFC: Documenting changes in the CHANGES file

On 6/2/20 2:17 PM, Stefan Eissing wrote: > >> Am 02.06.2020 um 14:11 schrieb Daniel Ruggeri : >> >> On 6/1/2020 6:23 AM, Yann Ylavic wrote: >>> On Fri, May 29, 2020 at 9:30 PM Ruediger Pluem >>> wrote: >>> Reviewing our backport process I noticed that in many cases a clean merge vi

Re: RFC: Documenting changes in the CHANGES file

> Am 02.06.2020 um 14:11 schrieb Daniel Ruggeri : > > On 6/1/2020 6:23 AM, Yann Ylavic wrote: >> On Fri, May 29, 2020 at 9:30 PM Ruediger Pluem >> wrote: >> >>> Reviewing our backport process I noticed that in many cases a clean merge >>> via svn merge fails due to conflicts in CHANGES. Whil

Re: RFC: Documenting changes in the CHANGES file

On 6/1/2020 6:23 AM, Yann Ylavic wrote: > On Fri, May 29, 2020 at 9:30 PM Ruediger Pluem wrote: >> Reviewing our backport process I noticed that in many cases a clean merge >> via svn merge fails due to conflicts in CHANGES. While >> these are easy to solve it puts IMHO unnecessary extra work on

Re: RFC: Documenting changes in the CHANGES file

On Fri, May 29, 2020 at 3:30 PM Ruediger Pluem wrote: > > Reviewing our backport process I noticed that in many cases a clean merge via > svn merge fails due to conflicts in CHANGES. While > these are easy to solve it puts IMHO unnecessary extra work on the backport > process, both for reviewing

Re: RFC: Documenting changes in the CHANGES file

On 29 May 2020, at 21:30, Ruediger Pluem wrote: > Reviewing our backport process I noticed that in many cases a clean merge via > svn merge fails due to conflicts in CHANGES. While > these are easy to solve it puts IMHO unnecessary extra work on the backport > process, both for reviewing and fo

Re: RFC: Documenting changes in the CHANGES file

Works for me. > On May 29, 2020, at 3:30 PM, Ruediger Pluem wrote: > > Reviewing our backport process I noticed that in many cases a clean merge via > svn merge fails due to conflicts in CHANGES. While > these are easy to solve it puts IMHO unnecessary extra work on the backport > process, bot

Re: RFC: Documenting changes in the CHANGES file

On Fri, May 29, 2020 at 9:30 PM Ruediger Pluem wrote: > > Reviewing our backport process I noticed that in many cases a clean merge via > svn merge fails due to conflicts in CHANGES. While > these are easy to solve it puts IMHO unnecessary extra work on the backport > process, both for reviewing

RFC: Documenting changes in the CHANGES file

Reviewing our backport process I noticed that in many cases a clean merge via svn merge fails due to conflicts in CHANGES. While these are easy to solve it puts IMHO unnecessary extra work on the backport process, both for reviewing and for actually doing the backport. How about if we change the

Re: RFC: mod_ssl features to dump for 2.5

On 5/6/20 1:01 PM, Joe Orton wrote: > On Wed, May 06, 2020 at 11:44:37AM +0100, Joe Orton wrote: >> On Mon, May 04, 2020 at 05:23:23PM +0200, Ruediger Pluem wrote: >>> On 5/4/20 3:49 PM, Joe Orton wrote: d) SSLRandomSeed. This might have made sense in 1998 but at least with OpenSSL 1.1.

Re: RFC: mod_ssl features to dump for 2.5

On Wed, May 06, 2020 at 11:44:37AM +0100, Joe Orton wrote: > On Mon, May 04, 2020 at 05:23:23PM +0200, Ruediger Pluem wrote: > > On 5/4/20 3:49 PM, Joe Orton wrote: > > > d) SSLRandomSeed. This might have made sense in 1998 but at least with > > > OpenSSL 1.1.1 which has a rewritten and fork-safe

Re: RFC: mod_ssl features to dump for 2.5

On Mon, May 04, 2020 at 05:23:23PM +0200, Ruediger Pluem wrote: > On 5/4/20 3:49 PM, Joe Orton wrote: > > d) SSLRandomSeed. This might have made sense in 1998 but at least with > > OpenSSL 1.1.1 which has a rewritten and fork-safe RAND, I think httpd > > should not be doing RAND seeding ever. C

Re: RFC: mod_ssl features to dump for 2.5

On 5/4/20 3:49 PM, Joe Orton wrote: > I'd like to gauge consensus on removing the following mod_ssl features > for 2.5. I am +1 (more or less strongly) on removing all the following: > > a) SSLInsecureRengotiation. If you haven't patched your clients for > CVE-2009-3555 there is no hope. T

Re: RFC: mod_ssl features to dump for 2.5

On Mon, May 04, 2020 at 09:59:24AM -0400, Eric Covener wrote: > On Mon, May 4, 2020 at 9:49 AM Joe Orton wrote: > > c) Client-initiated renegotiation prevention mechanism. This was > > introduced mostly as a temporary workaround for CVE-2009-3555, and as > > the saying goes, there is nothing as p

Re: RFC: mod_ssl features to dump for 2.5

On Mon, May 4, 2020 at 9:49 AM Joe Orton wrote: > > I'd like to gauge consensus on removing the following mod_ssl features > for 2.5. I am +1 (more or less strongly) on removing all the following: > > a) SSLInsecureRengotiation. If you haven't patched your clients for > CVE-2009-3555 there is no

RFC: mod_ssl features to dump for 2.5

I'd like to gauge consensus on removing the following mod_ssl features for 2.5. I am +1 (more or less strongly) on removing all the following: a) SSLInsecureRengotiation. If you haven't patched your clients for CVE-2009-3555 there is no hope. This should definitely be removed. b) SSLRequire

[RFC] static type checking for AP_INIT_FLAG etc

Another one I'd like to check consensus on, before disappearing too far down the rabbit-hole. The ap_set_*_slot directive function initializers throw away type safety completely since you can pass anything to APR_OFFSETOF(x,y) and it's cast to void * regardless. I've seen one bug because of th

Re: [RFC] optional Listen options= argument

On 4/21/20 6:02 PM, Joe Orton wrote: > On Tue, Apr 21, 2020 at 03:13:47PM +0100, Joe Orton wrote: >> On Tue, Apr 21, 2020 at 03:37:04PM +0200, Ruediger Pluem wrote: >>> Shouldn't that be argc < 2? >> >> It is < 3 to make the second arg truly optional, so a proto default is > > No, you were rig

Re: [RFC] optional Listen options= argument

On Tue, Apr 21, 2020 at 03:13:47PM +0100, Joe Orton wrote: > On Tue, Apr 21, 2020 at 03:37:04PM +0200, Ruediger Pluem wrote: > > Shouldn't that be argc < 2? > > It is < 3 to make the second arg truly optional, so a proto default is No, you were right the logic was borked. Updated patch which fi

Re: [RFC] optional Listen options= argument

On Tue, Apr 21, 2020 at 4:13 PM Joe Orton wrote: > > If it is safe to assume "=" can never appear in a > protocol name, we could catch any proto with "=" and make that a config > error again. Looks sensible to me, the proto is supposed to be a scheme (so ALNUM or [.+-], IIRC).

Re: [RFC] optional Listen options= argument

On Tue, Apr 21, 2020 at 2:53 PM Joe Orton wrote: > > Opinions? Is there still consensus that extending Listen like this is a > good idea? +1, nice. I also like that we can set reuseport without ListenCoresBucketsRatio > 0, both are orthogonal I think.

Re: [RFC] optional Listen options= argument

On Tue, Apr 21, 2020 at 03:37:04PM +0200, Ruediger Pluem wrote: > Looks good in general apart from the comment below. > > On 4/21/20 2:53 PM, Joe Orton wrote: > > @@ -1058,7 +1104,24 @@ AP_DECLARE_NONSTD(const char *) > > ap_set_listener(cmd_parms *cmd, void *dummy, > > return "Port must

Re: [RFC] optional Listen options= argument

Looks good in general apart from the comment below. On 4/21/20 2:53 PM, Joe Orton wrote: > @@ -1058,7 +1104,24 @@ AP_DECLARE_NONSTD(const char *) > ap_set_listener(cmd_parms *cmd, void *dummy, > return "Port must be specified"; > } > > -if (argc != 2) { > +if (argc == 3) {

Re: [RFC] optional Listen options= argument

On Tue, Apr 21, 2020 at 3:12 PM Eric Covener wrote: > > On Tue, Apr 21, 2020 at 8:53 AM Joe Orton wrote: > > > > A previous conversation [1] about optionally enabling socket options for > > Listen seemed to gain consensus around adding an optional argument, > > rather than multiple alternative Li

Re: [RFC] optional Listen options= argument

On Tue, Apr 21, 2020 at 8:53 AM Joe Orton wrote: > > A previous conversation [1] about optionally enabling socket options for > Listen seemed to gain consensus around adding an optional argument, > rather than multiple alternative Listen-like directives. > > I've attached a patch based on work by

[RFC] optional Listen options= argument

A previous conversation [1] about optionally enabling socket options for Listen seemed to gain consensus around adding an optional argument, rather than multiple alternative Listen-like directives. I've attached a patch based on work by both Jan Kaluza and Lubos Uhliarik which implements this,

Re: [RFC] fixing mod_cgid error logging

If anybody is interested to test this out I have a 2.4.x backport here: http://people.apache.org/~jorton/httpd-2.4.x-cgid-fdpassing.patch which ignores the configure test and hard-codes to enabling the new code (unlike code in trunk). I think we're now at parity between mod_cgi and mod_cgid in

Re: [RFC] fixing mod_cgid error logging

On Fri, Jul 05, 2019 at 01:39:21PM +0200, Ruediger Pluem wrote: > How much portable is this and do we have / should have something in > APR that does that portability? We probably should guard this with a > check for > > #ifndef CMSG_DATA > #error This module only works on unix platforms with th

Re: [RFC] fixing mod_cgid error logging

On 07/05/2019 12:57 PM, Joe Orton wrote: > PR 54211 and 60692 track a design problem in mod_cgid: the stderr of > spawned CGI scripts is a copy of the main server's stderr. This is a > significant regression from mod_cgi (you lose logging prefixes, > per-vhost config, non-file/pipe-logging p

Re: [RFC] fixing mod_cgid error logging

No objections from me, as I lack the expertise here. Patch looks readable, though. ;) > Am 05.07.2019 um 12:57 schrieb Joe Orton : > > PR 54211 and 60692 track a design problem in mod_cgid: the stderr of > spawned CGI scripts is a copy of the main server's stderr. This is a > significant regr

[RFC] fixing mod_cgid error logging

PR 54211 and 60692 track a design problem in mod_cgid: the stderr of spawned CGI scripts is a copy of the main server's stderr. This is a significant regression from mod_cgi (you lose logging prefixes, per-vhost config, non-file/pipe-logging provider support e.g. syslog) I can think of two mai

PATCH&RFC: "persistent state" directory default/config/API

On Fri, Sep 28, 2018 at 11:22:22AM +0100, Joe Orton wrote: > Example users are the mod_dav_fs lock database, mod_md's MD data store. > With an API & default, these can have hard-coded default paths so the > modules work without needing configuration. The proxy cache root could > count here too.

RFC: "persistent state" directory default/config/API

I'd like to add a "persistent state" directory with a hard-coded default, config directive and API equivalent to the runtimdir in config.layout, DefaultRuntimeDir directive and ap_runtime_dir_relative(). The "runtime" directory is used for transient state which disappears and can be deleted on

Re: [RFC/PATCH] mpm_winnt: Fix several issues in the child process shutdown logic

Evgeny Kotkov writes: > (1) As a part of the process of shutting down worker threads, the code > around child.c:1170 currently posts an amount of I/O completion packets > equal to the amount of the threads blocked on the I/O completion port. > Then it sleeps until all these thread

[RFC/PATCH] mpm_winnt: Fix several issues in the child process shutdown logic

Hi all, Recently we (Ivan Zhakov and I) found several issues in the code responsible for shutting down a mpm_winnt's child process. The attached patch should fix these issues: (Please note that the changes are combined into a single patch to make the review easier, but I'll commit them indepe

Re: [RFC] ?

On 03/08/2017 02:29 AM, Joe Orton wrote: Final call for yay/nay? Works great on my machine, +1! --Jacob

Re: [RFC] ?

On Mar 8, 2017 4:29 AM, "Joe Orton" wrote: Sorry, taking my time here, and I appreciate all the feedback. Definitely happier to debate it and get it right than be lumbered with annoying edge cases forever. I did the refactoring in r1785943, so third iteration attached has both and . I'd have

Re: [RFC] ?

+1 > Am 08.03.2017 um 11:29 schrieb Joe Orton : > > Stefan Eissing bytes GmbH Hafenstrasse 16 48155 Münster www.greenbytes.de

AW: [RFC] ?

+1 Regards Rüdiger > -Ursprüngliche Nachricht- > Von: Joe Orton [mailto:jor...@redhat.com] > Gesendet: Mittwoch, 8. März 2017 11:30 > An: dev@httpd.apache.org > Betreff: Re: [RFC] ? > > On Tue, Mar 07, 2017 at 11:52:17AM -0800, Jacob Champion wrote: > > On

Re: [RFC] ?

On Tue, Mar 07, 2017 at 11:52:17AM -0800, Jacob Champion wrote: > On 02/28/2017 04:32 PM, Jacob Champion wrote: > > I just don't like hamstringing a nice new directive with what's > > effectively a (rare) bug. > > (The conversation kinda died shortly after I said this. That was not my > intent --

Re: [RFC] ?

On 02/28/2017 04:32 PM, Jacob Champion wrote: I just don't like hamstringing a nice new directive with what's effectively a (rare) bug. (The conversation kinda died shortly after I said this. That was not my intent -- I like this directive a lot. Whether the consensus is to keep the corner ca

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

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

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

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

Re: [RFC] ?

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 > confl

Re: [RFC] ?

On Wed, Feb 22, 2017 at 11:47 AM, Joe Orton wrote: > > It actually only works like: > > > > which is a bit ugly. Quoting the argument is a syntax error. Not sure > how best to handle this. > > (b) for match both "foo" and " > (In core.c the start_if* code is mostly common across all the funct

Re: [RFC] ?

On Wed, Feb 22, 2017 at 8:43 AM, William A Rowe Jr wrote: > I was more concerned about our support for ... > I'd really like to see mod_version go away in 2.next and force > the availability of that feature so that .conf authors are assured > of it's presence moving forwards. +1 -- Eric Covener

Re: [RFC] ?

On Wed, Feb 22, 2017 at 1:04 AM, Nick Kew wrote: > On Tue, 2017-02-21 at 21:58 +, Joe Orton wrote: > >> Any reason is a bad idea, so we can do that more cleanly >> (... in a couple of decades time)? > > One reason it might be a very bad idea: user confusion! > > I'm thinking of the track reco

Re: [RFC] ?

On Tue, Feb 21, 2017 at 02:28:52PM -0800, Jacob Champion wrote: > I haven't tried your patch yet, but from inspection it looks like you'd have > to do something like this if you're looking for a : > > > ... > > (Note the missing closing angle bracket in the argument.) Assuming I've r

Re: [RFC] ?

Neat! +1 > Am 21.02.2017 um 22:58 schrieb Joe Orton : > > For cases like HttpProtocolOptions where a new directive is introduced > to multiple active branches simultaneously, it gets awkward to use > to write conf files which use the new directive but are > compatible across multiple versions

Re: [RFC] ?

On Tue, 2017-02-21 at 21:58 +, Joe Orton wrote: > Any reason is a bad idea, so we can do that more cleanly > (... in a couple of decades time)? One reason it might be a very bad idea: user confusion! I'm thinking of the track record of here. Our support fora are full of users who have see

Re: [RFC] ?

Am 21.02.2017 um 23:24 schrieb Eric Covener: On Tue, Feb 21, 2017 at 5:20 PM, Reindl Harald wrote: Am 21.02.2017 um 22:58 schrieb Joe Orton: For cases like HttpProtocolOptions where a new directive is introduced to multiple active branches simultaneously, it gets awkward to use to write

Re: [RFC] ?

On 02/21/2017 01:58 PM, Joe Orton wrote: Any reason is a bad idea, so we can do that more cleanly (... in a couple of decades time)? I like it! It would be really useful for running bisections... once we're far enough in the future, that is. I currently have to comment out portions of the te

Re: [RFC] ?

On Tue, Feb 21, 2017 at 5:20 PM, Reindl Harald wrote: > > > Am 21.02.2017 um 22:58 schrieb Joe Orton: >> >> For cases like HttpProtocolOptions where a new directive is introduced >> to multiple active branches simultaneously, it gets awkward to use >> to write conf files which use the new directi

Re: [RFC] ?

Am 21.02.2017 um 22:58 schrieb Joe Orton: For cases like HttpProtocolOptions where a new directive is introduced to multiple active branches simultaneously, it gets awkward to use to write conf files which use the new directive but are compatible across multiple versions. Triggered by a conve

Re: [RFC] ?

On Tue, Feb 21, 2017 at 4:58 PM, Joe Orton wrote: > For cases like HttpProtocolOptions where a new directive is introduced > to multiple active branches simultaneously, it gets awkward to use > to write conf files which use the new directive but are > compatible across multiple versions. > > Trig

[RFC] ?

For cases like HttpProtocolOptions where a new directive is introduced to multiple active branches simultaneously, it gets awkward to use to write conf files which use the new directive but are compatible across multiple versions. Triggered by a conversation with a user, but also e.g. see curr

Re: [PATCH] on TRACE & RFC compliance

Thanks a lot, all. I dropped the last sentence and pushed to trunk & 2.4.x. r1750750 & r1750752

Re: [PATCH] on TRACE & RFC compliance

On 06/29/2016 02:44 PM, Eric Covener wrote: > On Wed, Jun 29, 2016 at 8:08 AM, William A Rowe Jr > wrote: >> The wording change seems fine to me, I'd actually be fine with simply >> dropping >> your last sentence entirely. Our config defaults speak for themselves. > > > I think the last sente

Re: [PATCH] on TRACE & RFC compliance

On Wed, Jun 29, 2016 at 8:08 AM, William A Rowe Jr wrote: > The wording change seems fine to me, I'd actually be fine with simply > dropping > your last sentence entirely. Our config defaults speak for themselves. I think the last sentence is a little strong too. People are just going to disabl

Re: [PATCH] on TRACE & RFC compliance

The wording change seems fine to me, I'd actually be fine with simply dropping your last sentence entirely. Our config defaults speak for themselves. On Wed, Jun 29, 2016 at 6:55 AM, Joe Orton wrote: > We had a couple of people complaining about the language around TRACE in > the docs, which say

[PATCH] on TRACE & RFC compliance

We had a couple of people complaining about the language around TRACE in the docs, which say disabling TRACE "makes your server noncompliant", a claim I found hard to support. All methods but HEAD and GET are defined as OPTIONAL, so I'm not sure how this is true, am I missing something? http

Re: RFC 7230..7235 Parsing Conformance?

from tchar are '"', '(', ')', ',', '/', > ':', ';', '<', '=', '>', '?', '@', '[', '\', ']', '{', '}' which > corresp

Re: RFC 7230..7235 Parsing Conformance?

Based on Jason's question... On Tue, May 17, 2016 at 1:31 PM, William A Rowe Jr wrote: > On Tue, May 17, 2016 at 1:00 PM, Julian Reschke > wrote: > >> On 2016-05-17 19:01, Graham Leggett wrote: >> >>> On 17 May 2016, at 6:43 PM, William A Rowe Jr >>> wrote: >>> >>> Wondering what other contrib

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 Tue, May 17, 2016 at 9:43 AM, William A Rowe Jr wrote: > Do we want to backport these changes to 2.4.x? If so, what > mechanism do we want to toggle the behavior of the server > between 2616 and 7230..7235? I would piggyback it on the "HttpProtocol" strict stuff that also needs backporting.

Re: RFC 7230..7235 Parsing Conformance?

On Tue, May 17, 2016 at 1:00 PM, Julian Reschke wrote: > On 2016-05-17 19:01, Graham Leggett wrote: > >> On 17 May 2016, at 6:43 PM, William A Rowe Jr >> wrote: >> >> Wondering what other contributors are thinking on this topic. >>> >>> We have a number of changes in the ABNF grammar between >>>

Re: RFC 7230..7235 Parsing Conformance?

On 2016-05-17 19:01, Graham Leggett wrote: On 17 May 2016, at 6:43 PM, William A Rowe Jr wrote: Wondering what other contributors are thinking on this topic. We have a number of changes in the ABNF grammar between RFC2616 and RFC7230..7235. Do we want trunk 2.6/3.0 to be an entirely RFC723x g

Re: RFC 7230..7235 Parsing Conformance?

On 17 May 2016, at 6:43 PM, William A Rowe Jr wrote: > Wondering what other contributors are thinking on this topic. > > We have a number of changes in the ABNF grammar between > RFC2616 and RFC7230..7235. Do we want trunk 2.6/3.0 to be > an entirely RFC723x generation server, and drop all supp

RFC 7230..7235 Parsing Conformance?

Wondering what other contributors are thinking on this topic. We have a number of changes in the ABNF grammar between RFC2616 and RFC7230..7235. Do we want trunk 2.6/3.0 to be an entirely RFC723x generation server, and drop all support for RFC2616? Do we want to backport these changes to 2.4.x? I

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

Re: [RFC] Enable OCSP Stapling by default in httpd trunk

On Sep 6, 2015 8:09 AM, "Kaspar Brand" wrote: > > On 05.09.2015 13:06, Tim Bannister wrote: > > It's not just conventional browsers. I think automated / embedded > > HTTP clients will also benefit from stapling, either because > > networking filters would block a conversation between the client an

Re: [RFC] Enable OCSP Stapling by default in httpd trunk

Am 06.09.2015 um 15:06 schrieb Kaspar Brand: Taking into account that OCSP responders from the big players are running on fairly robust infrastructure these days (cf. the sr.symcd.com example, aka ocsp.verisign.net, aka ocsp.ws.symantec.com.edgekey.net), I'm not buying the "OCSP is unreliable"

Re: [RFC] Enable OCSP Stapling by default in httpd trunk

On 05.09.2015 14:23, Jeff Trawick wrote: > On 09/04/2015 10:59 AM, Kaspar Brand wrote: >>> 1. The default configuration should not trigger unsolicited outgoing >>> queries to untrusted systems, for both a) and b), that's how I would put it. > > Re: "unsolicited": > > Key words/phrases from the ot

Re: [RFC] Enable OCSP Stapling by default in httpd trunk

On 05.09.2015 13:06, Tim Bannister wrote: > It's not just conventional browsers. I think automated / embedded > HTTP clients will also benefit from stapling, either because > networking filters would block a conversation between the client and > the CA's OCSP responder, or the extra latency from us

Re: [RFC] Enable OCSP Stapling by default in httpd trunk

On 05.09.2015 12:53, Ben Laurie wrote: > On Sat, 5 Sep 2015 at 09:32 Kaspar Brand wrote: >> I'm also very sceptical that a higher percentage of handshakes with >> stapled responses (how much exactly?) will lead browser vendors to >> switch to hard fail - as the test-sspev.verisign.com example from

Re: [RFC] Enable OCSP Stapling by default in httpd trunk

On 09/04/2015 10:59 AM, Kaspar Brand wrote: On 02.09.2015 01:54, Jeff Trawick wrote: On 08/30/2015 02:30 AM, Kaspar Brand wrote: today's situation, because this assessment misses the fact that with the current RFC-6066-based implementation, stapling can't fully achieve the goal of

Re: [RFC] Enable OCSP Stapling by default in httpd trunk

On 5 Sep 2015, at 11:53, Ben Laurie wrote: > On Sat, 5 Sep 2015 at 09:32 Kaspar Brand wrote: >> On 04.09.2015 17:54, Rob Stradling wrote: >>> Today, roughly 25% of HTTPS servers on the Internet have OCSP stapling >>> enabled. Browsers aren't likely to start hard-failing by default until >>> th

Re: [RFC] Enable OCSP Stapling by default in httpd trunk

On Sat, 5 Sep 2015 at 09:32 Kaspar Brand wrote: > On 04.09.2015 17:54, Rob Stradling wrote: > > Today, roughly 25% of HTTPS servers on the Internet have OCSP stapling > > enabled. Browsers aren't likely to start hard-failing by default until > > that % is a lot higher. > > > > The vast majority

Re: [RFC] Enable OCSP Stapling by default in httpd trunk

On 04.09.2015 17:54, Rob Stradling wrote: > Today, roughly 25% of HTTPS servers on the Internet have OCSP stapling > enabled. Browsers aren't likely to start hard-failing by default until > that % is a lot higher. > > The vast majority of the servers that have OCSP stapling enabled are > running

Re: [RFC] Enable OCSP Stapling by default in httpd trunk

On 04/09/15 15:59, Kaspar Brand wrote: > On 02.09.2015 01:54, Jeff Trawick wrote: >> On 08/30/2015 02:30 AM, Kaspar Brand wrote: >>> today's situation, because this assessment misses the fact that with the >>> current RFC-6066-based implementation, stapling can

Re: [RFC] Enable OCSP Stapling by default in httpd trunk

On 02.09.2015 01:54, Jeff Trawick wrote: > On 08/30/2015 02:30 AM, Kaspar Brand wrote: >> today's situation, because this assessment misses the fact that with the >> current RFC-6066-based implementation, stapling can't fully achieve the >> goal of obviating OCS

Re: [RFC] Enable OCSP Stapling by default in httpd trunk

. I have some doubts whether "widely accepted" is an accurate summary of today's situation, because this assessment misses the fact that with the current RFC-6066-based implementation, stapling can't fully achieve the goal of obviating OCSP queries for the clients - all publ

Re: [RFC] Enable OCSP Stapling by default in httpd trunk

On 08/29/2015 08:10 PM, William A Rowe Jr wrote: On Aug 29, 2015 1:49 PM, "Jeff Trawick" > wrote: > > On 08/28/2015 04:17 PM, Tim Bannister wrote: >> >> Jeff Trawick mailto:traw...@gmail.com>> wrote: >>> >>> >>> As of now there's still a veto on my suggestion of enabli

Re: [RFC] Enable OCSP Stapling by default in httpd trunk

to enable. > > I have some doubts whether "widely accepted" is an accurate summary of > today's situation, because this assessment misses the fact that with the > current RFC-6066-based implementation, stapling can't fully achieve the > goal of obviating OCSP

Re: AW: [RFC] Enable OCSP Stapling by default in httpd trunk

On 29.08.2015 17:56, olli hauer wrote: > On 2015-07-03 12:13, Plüm, Rüdiger, Vodafone Group wrote: >> Thanks for the detailed explanation. So yes OCSP stapling is really >> beneficial if it is possible for the server admin to set it up. But >> it likely requires additional configuration steps outsi

Re: [RFC] Enable OCSP Stapling by default in httpd trunk

r "widely accepted" is an accurate summary of today's situation, because this assessment misses the fact that with the current RFC-6066-based implementation, stapling can't fully achieve the goal of obviating OCSP queries for the clients - all publicly trusted CAs use hierarchies

Re: [RFC] Enable OCSP Stapling by default in httpd trunk

On Aug 29, 2015 1:49 PM, "Jeff Trawick" wrote: > > On 08/28/2015 04:17 PM, Tim Bannister wrote: >> >> Jeff Trawick wrote: >>> >>> >>> As of now there's still a veto on my suggestion of enabling stapling by >>> default in the httpd trunk config. >> >> Would that default need to be backported to 2.

  1   2   3   4   5   6   >