Bug report for Apache httpd-2 [2017/12/03]

2017-12-02 Thread bugzilla 
+---+
| Bugzilla Bug ID   |
| +-+
| | Status: UNC=Unconfirmed NEW=New ASS=Assigned|
| | OPN=ReopenedVER=Verified(Skipped Closed/Resolved)   |
| |   +-+
| |   | Severity: BLK=Blocker CRI=Critical  REG=Regression  MAJ=Major   |
| |   |   MIN=Minor   NOR=NormalENH=Enhancement TRV=Trivial |
| |   |   +-+
| |   |   | Date Posted |
| |   |   |  +--+
| |   |   |  | Description  |
| |   |   |  |  |
| 8713|Inf|Min|2002-05-01|No Errorlog on PROPFIND/Depth:Infinity|
| 8867|Opn|Cri|2002-05-07|exports.c generation fails when using a symlink to|
|10747|New|Maj|2002-07-12|ftp SIZE command and 'smart' ftp servers results i|
|11294|New|Enh|2002-07-30|desired vhost_alias option|
|11580|Opn|Enh|2002-08-09|generate Content-Location headers |
|12033|Opn|Nor|2002-08-26|Graceful restart immediately result in [warn] long|
|13599|Inf|Nor|2002-10-14|autoindex formating broken for multibyte sequences|
|13661|Ass|Enh|2002-10-15|Apache cannot not handle dynamic IP reallocation  |
|14104|Opn|Enh|2002-10-30|not documented: must restart server to load new CR|
|14496|New|Enh|2002-11-13|Cannot upgrade any version on Windows. Must uninst|
|14922|Inf|Enh|2002-11-28| is currently hardcoded to 'apache2'  |
|15719|Inf|Nor|2002-12-30|WebDAV MOVE to destination URI which is content-ne|
|16761|Inf|Nor|2003-02-04|CustomLog with pipe spawns process during config  |
|16811|Ass|Maj|2003-02-05|mod_autoindex always return webpages in UTF-8.|
|17107|New|Min|2003-02-16|Windows should not install printenv   |
|17114|New|Enh|2003-02-17|Please add strip and install-strip targets to Make|
|17244|Ass|Nor|2003-02-20|./configure --help gives false information regardi|
|17497|Opn|Nor|2003-02-27|mod_mime_magic generates incorrect response header|
|18325|New|Enh|2003-03-25|PAM support for suEXEC|
|18334|Inf|Cri|2003-03-25|Server crashes when authenticating users against L|
|19670|New|Enh|2003-05-05|content type header supplied upon PUT is thrown aw|
|20036|Ass|Nor|2003-05-19|Trailing Dots stripped from PATH_INFO environment |
|21260|New|Nor|2003-07-02|CacheMaxExpire directive not enforced !   |
|21533|Ass|Cri|2003-07-11|Multiple levels of htacces files can cause mod_aut|
|22484|Opn|Maj|2003-08-16|semaphore problem takes httpd down|
|22686|Opn|Nor|2003-08-25|ab: apr_poll: The timeout specified has expired (7|
|22898|Opn|Nor|2003-09-02|nph scripts with two HTTP header  |
|23167|Inf|Cri|2003-09-14|--enable-layout never goes to apr apr-util|
|23181|New|Nor|2003-09-15|Status 304 (Not modified) and chunking leads to an|
|23238|New|Cri|2003-09-18|non-async-signal-safe operations from signal handl|
|23330|New|Enh|2003-09-22|Enhance ApacheMonitor to view and control Tomcat s|
|23911|Opn|Cri|2003-10-18|CGI processes left defunct/zombie under 2.0.54|
|24031|New|Enh|2003-10-23|Passphrase protected private key in SSLProxyMachin|
|24095|Opn|Cri|2003-10-24|ERROR "Parent: child process exited with status 32|
|24437|Opn|Nor|2003-11-05|mod_auth_ldap doubly-escapes backslash (\) charact|
|24890|Opn|Nor|2003-11-21|Apache config parser should not be local aware ( g|
|25014|New|Enh|2003-11-26|A flexible interface for mod_log_config   |
|25201|New|Enh|2003-12-04|Provide Cache Purge operation |
|25240|Inf|Enh|2003-12-05|SSL Library Error: 336105671 logged as information|
|25435|New|Enh|2003-12-11|sethandler and directoryindex not playing nice|
|25469|Opn|Enh|2003-12-12|create AuthRoot for defining paths to auth files  |
|25484|Ass|Nor|2003-12-12|Non-service Apache cannot be stopped in WinXP |
|25543|Inf|Nor|2003-12-15|mod_proxy_ajp overwrites existing response headers|
|25667|New|Nor|2003-12-19|Memory leak in function ssl_scache_dbm_retrieve().|
|25863|New|Enh|2004-01-02|new per-host initialization hooks |
|26005|New|Nor|2004-01-08|SERVER_NAME incorrect when using IPv6 address in U|
|26142|New|Maj|2004-01-14|EnableSendFile Off for Windows XP Home|
|26153|Opn|Cri|2004-01-15|Apache cygwin directory traversal vulnerability   |
|26368|New|Min|2004-01-23|File extensions in AddDescription treated as part |
|26446|New|Nor|2004-01-26|flush buckets followed by eos bucket emit multiple|
|26478|New|Enh|2004-01-28|mod_dav does not expose a method for setting the D|

Re: apache 2.4.29: mod_http2 stucks from time to time

2017-12-02 Thread Stefan Eissing 
The fix went into trunk as r1816619 and in 2.4.x as r1816969 in 2.4.x.

Cheers,

Stefan

> Am 02.12.2017 um 09:23 schrieb Luca Toscano :
> 
> Hi everybody,
> 
> did I miss an update or are we still waiting for more data? (Don't mean to 
> rush you Stefan, just to understand what's the status of the thread :)
> 
> Luca
> 
> 2017-11-24 15:26 GMT+01:00 Stefan Priebe - Profihost AG 
> :
> Thanks i‘ll post a log tonight with a 120s stalled request.
> 
> Greets,
> Stefan
> 
> Excuse my typo sent from my mobile phone.
> 
> Am 23.11.2017 um 17:09 schrieb Stefan Eissing :
> 
>> Hey,
>> 
>> could you try the patch below and produce such a lovely log file again? 
>> H2MaxWorkers please back to before, unconfigured. Thanks! This is a small 
>> change that a) logs the interaction with h2_workers a bit more and makes 
>> sure that time gets lost where I think it does. It also switches the fifo 
>> queue in set mode where duplicate entries are checked, in case that 
>> interferes here.
>> 
>> Cheers,
>> 
>> Stefan
>> 
>> 
>> 
>> 
>>> Am 23.11.2017 um 14:16 schrieb Stefan Priebe - Profihost AG 
>>> :
>>> 
>>> Hi,
>>> Am 23.11.2017 um 14:10 schrieb Stefan Eissing:
 Interesting. I assume that otherwise this host is the same (OS/CPU etc.) 
 as others where it runs without probs?
>>> 
>>> Yes and no i got some more reports by colleagues where they've disabled
>>> http2 as the customers had unexpected long loading times.
>>> 
 We are not ghosted by some strange blabla-lake hyper threading thingie 
 singularity?
>>> 
>>> Huhoh what's that? Any chance to add some more debugging?
>>> 
>>> Greets,
>>> Stefan
>>> 
 
 Need to think about this.
 
> Am 23.11.2017 um 13:43 schrieb Stefan Priebe - Profihost AG 
> :
> 
> *argh*, i was too fast no it did NOT fix the problem. It even happens 
> with:
> H2MaxWorkers4096
> 
> Sorry about that.
> 
> Stefan
> 
> Am 23.11.2017 um 13:42 schrieb Stefan Priebe - Profihost AG:
>> Hello,,
>> 
>> setting:
>> H2MaxWorkers1024
>> 
>> fixes the issue for me. The main problem is how to i know how many
>> workers are needed? How can i detect whether all workers of h2 are busy?
>> 
>> Stefan
>> 
>> Am 22.11.2017 um 13:23 schrieb Stefan Priebe - Profihost AG:
>>> Hell Stefan,
>>> 
>>> will send a log to you in a few seconds via private email.
>>> 
>>> Greets,
>>> Stefan
>>> 
>>> Am 21.11.2017 um 23:18 schrieb Stefan Eissing:
 sorry for the late reply. for stucks trace2 is best. 
 
> Am 21.11.2017 um 19:35 schrieb Stefan Priebe - Profihost AG 
> :
> 
> Hello Stefan,
> 
> which loglevel do you need? trace2?
> 
> Greets,
> Stefan
> 
>> Am 21.11.2017 um 16:48 schrieb Stefan Eissing:
>> Never done this, but https://www.howtoforge.com/setenvif_apache2 
>> seems like one way to do make it work.
>> 
>>> Am 21.11.2017 um 16:16 schrieb Stefan Priebe - Profihost AG 
>>> :
>>> 
>>> 
 Am 21.11.2017 um 16:06 schrieb Stefan Priebe - Profihost AG:
> Am 21.11.2017 um 15:45 schrieb Stefan Eissing:
> 
>> Am 21.11.2017 um 14:33 schrieb Stefan Priebe - Profihost AG 
>> :
>> 
>> Hello Stefan,
>> Hello Yann,
>> 
>> me the http2 bug tester is calling again ;-)
> 
> And the day was going so well...
 
 I'm sorry ;-)
 
>> While running two bash curl while loops the one using http1.1 
>> always
>> finishes in < 0.05s while the http2 one takes sometimes 0.4 to 
>> 20s to
>> finish. Sadly i can't reproduce this all the time - mostly more 
>> requests
>> more failures. As this is a production server i've no idea how 
>> to debug
>> as the http2 trace logs might flood the harddisk.
> 
> Hmmm. Do you know if this happens waiting for a response or at 
> the end of a connection? Or in the middle of a body? All GETs or 
> also POSTs?
 
 My Test only contains GET - but most probably there are also 
 running
 POST requests but not started by me.
 
 Strangely this only happens between 1pm and 2pm a day but i've no 
 idea
 what's different at that time.
>>> 
>>> OK i'm also able to reproduce this whenever your want. Can we 
>>> activate
>>> trace logging for a specific IP? So i can

Re: apache 2.4.29: mod_http2 stucks from time to time

2017-12-02 Thread Stefan Priebe - Profihost AG 
Hello,

here is the relevant commit:
https://github.com/icing/mod_h2/commit/51085e0c26da1f47ea9cf91930af8cef0dececb9

Stefan

Excuse my typo sent from my mobile phone.

> Am 02.12.2017 um 14:39 schrieb Stefan Priebe - Profihost AG 
> :
> 
> Hello Luca,
> 
> It’s a problem with the limited fifo queue size of http2.
> 
> Stefan send me a workaround not sure if this one will go into http2 or if he 
> will release a real fix soon.
> 
> Greets,
> Stefan
> 
> Excuse my typo sent from my mobile phone.
> 
>> Am 02.12.2017 um 09:23 schrieb Luca Toscano :
>> 
>> Hi everybody,
>> 
>> did I miss an update or are we still waiting for more data? (Don't mean to 
>> rush you Stefan, just to understand what's the status of the thread :)
>> 
>> Luca
>> 
>> 2017-11-24 15:26 GMT+01:00 Stefan Priebe - Profihost AG 
>> :
>>> Thanks i‘ll post a log tonight with a 120s stalled request.
>>> 
>>> Greets,
>>> Stefan
>>> 
>>> Excuse my typo sent from my mobile phone.
>>> 
 Am 23.11.2017 um 17:09 schrieb Stefan Eissing 
 :
 
 Hey,
 
 could you try the patch below and produce such a lovely log file again? 
 H2MaxWorkers please back to before, unconfigured. Thanks! This is a small 
 change that a) logs the interaction with h2_workers a bit more and makes 
 sure that time gets lost where I think it does. It also switches the fifo 
 queue in set mode where duplicate entries are checked, in case that 
 interferes here.
 
 Cheers,
 
 Stefan
 
 
 
 
> Am 23.11.2017 um 14:16 schrieb Stefan Priebe - Profihost AG 
> :
> 
> Hi,
>> Am 23.11.2017 um 14:10 schrieb Stefan Eissing:
>> Interesting. I assume that otherwise this host is the same (OS/CPU etc.) 
>> as others where it runs without probs?
> 
> Yes and no i got some more reports by colleagues where they've disabled
> http2 as the customers had unexpected long loading times.
> 
>> We are not ghosted by some strange blabla-lake hyper threading thingie 
>> singularity?
> 
> Huhoh what's that? Any chance to add some more debugging?
> 
> Greets,
> Stefan
> 
>> 
>> Need to think about this.
>> 
>>> Am 23.11.2017 um 13:43 schrieb Stefan Priebe - Profihost AG 
>>> :
>>> 
>>> *argh*, i was too fast no it did NOT fix the problem. It even happens 
>>> with:
>>> H2MaxWorkers4096
>>> 
>>> Sorry about that.
>>> 
>>> Stefan
>>> 
 Am 23.11.2017 um 13:42 schrieb Stefan Priebe - Profihost AG:
 Hello,,
 
 setting:
 H2MaxWorkers1024
 
 fixes the issue for me. The main problem is how to i know how many
 workers are needed? How can i detect whether all workers of h2 are 
 busy?
 
 Stefan
 
> Am 22.11.2017 um 13:23 schrieb Stefan Priebe - Profihost AG:
> Hell Stefan,
> 
> will send a log to you in a few seconds via private email.
> 
> Greets,
> Stefan
> 
>> Am 21.11.2017 um 23:18 schrieb Stefan Eissing:
>> sorry for the late reply. for stucks trace2 is best. 
>> 
>>> Am 21.11.2017 um 19:35 schrieb Stefan Priebe - Profihost AG 
>>> :
>>> 
>>> Hello Stefan,
>>> 
>>> which loglevel do you need? trace2?
>>> 
>>> Greets,
>>> Stefan
>>> 
 Am 21.11.2017 um 16:48 schrieb Stefan Eissing:
 Never done this, but https://www.howtoforge.com/setenvif_apache2 
 seems like one way to do make it work.
 
> Am 21.11.2017 um 16:16 schrieb Stefan Priebe - Profihost AG 
> :
> 
> 
>>> Am 21.11.2017 um 16:06 schrieb Stefan Priebe - Profihost AG:
 Am 21.11.2017 um 15:45 schrieb Stefan Eissing:
 
 Am 21.11.2017 um 14:33 schrieb Stefan Priebe - Profihost AG 
 :
 
 Hello Stefan,
 Hello Yann,
 
 me the http2 bug tester is calling again ;-)
>>> 
>>> And the day was going so well...
>> 
>> I'm sorry ;-)
>> 
 While running two bash curl while loops the one using http1.1 
 always
 finishes in < 0.05s while the http2 one takes sometimes 0.4 to 
 20s to
 finish. Sadly i can't reproduce this all the time - mostly 
 more requests
 more failures. As this is a production server i've no idea how 
 to debug
 as the http2

Re: apache 2.4.29: mod_http2 stucks from time to time

2017-12-02 Thread Stefan Priebe - Profihost AG 
Hello Luca,

It’s a problem with the limited fifo queue size of http2.

Stefan send me a workaround not sure if this one will go into http2 or if he 
will release a real fix soon.

Greets,
Stefan

Excuse my typo sent from my mobile phone.

> Am 02.12.2017 um 09:23 schrieb Luca Toscano :
> 
> Hi everybody,
> 
> did I miss an update or are we still waiting for more data? (Don't mean to 
> rush you Stefan, just to understand what's the status of the thread :)
> 
> Luca
> 
> 2017-11-24 15:26 GMT+01:00 Stefan Priebe - Profihost AG 
> :
>> Thanks i‘ll post a log tonight with a 120s stalled request.
>> 
>> Greets,
>> Stefan
>> 
>> Excuse my typo sent from my mobile phone.
>> 
>>> Am 23.11.2017 um 17:09 schrieb Stefan Eissing 
>>> :
>>> 
>>> Hey,
>>> 
>>> could you try the patch below and produce such a lovely log file again? 
>>> H2MaxWorkers please back to before, unconfigured. Thanks! This is a small 
>>> change that a) logs the interaction with h2_workers a bit more and makes 
>>> sure that time gets lost where I think it does. It also switches the fifo 
>>> queue in set mode where duplicate entries are checked, in case that 
>>> interferes here.
>>> 
>>> Cheers,
>>> 
>>> Stefan
>>> 
>>> 
>>> 
>>> 
 Am 23.11.2017 um 14:16 schrieb Stefan Priebe - Profihost AG 
 :
 
 Hi,
> Am 23.11.2017 um 14:10 schrieb Stefan Eissing:
> Interesting. I assume that otherwise this host is the same (OS/CPU etc.) 
> as others where it runs without probs?
 
 Yes and no i got some more reports by colleagues where they've disabled
 http2 as the customers had unexpected long loading times.
 
> We are not ghosted by some strange blabla-lake hyper threading thingie 
> singularity?
 
 Huhoh what's that? Any chance to add some more debugging?
 
 Greets,
 Stefan
 
> 
> Need to think about this.
> 
>> Am 23.11.2017 um 13:43 schrieb Stefan Priebe - Profihost AG 
>> :
>> 
>> *argh*, i was too fast no it did NOT fix the problem. It even happens 
>> with:
>> H2MaxWorkers4096
>> 
>> Sorry about that.
>> 
>> Stefan
>> 
>>> Am 23.11.2017 um 13:42 schrieb Stefan Priebe - Profihost AG:
>>> Hello,,
>>> 
>>> setting:
>>> H2MaxWorkers1024
>>> 
>>> fixes the issue for me. The main problem is how to i know how many
>>> workers are needed? How can i detect whether all workers of h2 are busy?
>>> 
>>> Stefan
>>> 
 Am 22.11.2017 um 13:23 schrieb Stefan Priebe - Profihost AG:
 Hell Stefan,
 
 will send a log to you in a few seconds via private email.
 
 Greets,
 Stefan
 
> Am 21.11.2017 um 23:18 schrieb Stefan Eissing:
> sorry for the late reply. for stucks trace2 is best. 
> 
>> Am 21.11.2017 um 19:35 schrieb Stefan Priebe - Profihost AG 
>> :
>> 
>> Hello Stefan,
>> 
>> which loglevel do you need? trace2?
>> 
>> Greets,
>> Stefan
>> 
>>> Am 21.11.2017 um 16:48 schrieb Stefan Eissing:
>>> Never done this, but https://www.howtoforge.com/setenvif_apache2 
>>> seems like one way to do make it work.
>>> 
 Am 21.11.2017 um 16:16 schrieb Stefan Priebe - Profihost AG 
 :
 
 
>> Am 21.11.2017 um 16:06 schrieb Stefan Priebe - Profihost AG:
>>> Am 21.11.2017 um 15:45 schrieb Stefan Eissing:
>>> 
>>> Am 21.11.2017 um 14:33 schrieb Stefan Priebe - Profihost AG 
>>> :
>>> 
>>> Hello Stefan,
>>> Hello Yann,
>>> 
>>> me the http2 bug tester is calling again ;-)
>> 
>> And the day was going so well...
> 
> I'm sorry ;-)
> 
>>> While running two bash curl while loops the one using http1.1 
>>> always
>>> finishes in < 0.05s while the http2 one takes sometimes 0.4 to 
>>> 20s to
>>> finish. Sadly i can't reproduce this all the time - mostly more 
>>> requests
>>> more failures. As this is a production server i've no idea how 
>>> to debug
>>> as the http2 trace logs might flood the harddisk.
>> 
>> Hmmm. Do you know if this happens waiting for a response or at 
>> the end of a connection? Or in the middle of a body? All GETs or 
>> also POSTs?
> 
> My Test only contains GET - but most probably there are also 
> running
> POST requests but not started by me.
> 
>

Re: mod_rewrite, vary headers and internal redirects

2017-12-02 Thread Luca Toscano 
Bring up the subject again. I do think that having  and 
behaving in the same way when setting the Vary headers would be really
important, but I am not sure if this is a 2.5.x only change or if it is
worth to break the existing 2.4 behavior. Thoughts?

To summarize the current behavior:

1)  sets Vary:HeaderFoo to the response regardless
of condition being true or false.
2) RewriteCond HeaderFoo condition sets Vary:HeaderFoo only when condition
is true (we state it very clearly in the docs).

Luca

2017-10-27 18:48 GMT+02:00 Luca Toscano :

> Took a look to the following docs:
>
> https://docs.trafficserver.apache.org/en/5.3.x/admin/
> http-proxy-caching.en.html
> https://varnish-cache.org/docs/5.1/users-guide/
> increasing-your-hitrate.html
> https://www.fastly.com/blog/best-practices-using-vary-header/
>
> The last one contains an interesting bit: "Vary to the Rescue" (the
> Vary:Accept-Encoding header example).
>
> It seems to me that almost all caches expand their caching keys with
> whatever header is added to "Vary". From the example that I've read, the
> only fact that a response for the URI /foo/bar may be different if
> Header:something is present or not in the request indicates a good use case
> for adding Vary:something to the response. For a caching proxy in fact the
> absence of a Header will become part of a key:
>
> URI x + no Header:something --> cached object 1
> URI x + Header:something=foo -> cached object 2
> URI x + Header:something=bar -> cached object 3
> etc..
>
> The fine tuning of this behavior to avoid cache pollution or a low hit
> rate can be controlled in RewriteConds via the NV (no-vary) configuration,
> so it shouldn't be a big issue. I am more convinced that the  behavior
> is the right one to follow..
>
> Luca
>
>
>
> 2017-10-25 23:08 GMT+02:00 Luca Toscano :
>
>> Hi Ruediger,
>>
>> the following patch (still to be carefully tested and/or improved) should
>> force RewriteCond to behave like an  block adding the Vary header
>> simply if the condition is evaluated (so header value present in the
>> request but not satisfying the condition or header completely absent):
>>
>> http://home.apache.org/~elukey/httpd-trunk-mod_rewrite-add_
>> vary_header_always.patch
>>
>> It seems to be a big change in behavior though, I'd be curious to find
>> out the motivations of the implementation choice at the time (will try to
>> dig a bit into svn history).
>>
>> Thanks!
>>
>> Luca
>>
>> 2017-10-23 8:43 GMT+02:00 Plüm, Rüdiger, Vodafone Group <
>> ruediger.pl...@vodafone.com>:
>>
>>> I would tend to say that the  code is correct and the RewriteCond
>>> code is wrong, because it doesn’t matter if the condition becomes true or
>>> false. The headers value has an influence on the result. Tricky question is
>>> what to do regarding Vary if the non-presence of a header has an influence.
>>>
>>>
>>>
>>> Regards
>>>
>>>
>>>
>>> Rüdiger
>>>
>>>
>>>
>>> *Von:* Luca Toscano [mailto:toscano.l...@gmail.com]
>>> *Gesendet:* Sonntag, 22. Oktober 2017 11:47
>>> *An:* Apache HTTP Server Development List 
>>> *Betreff:* Re: mod_rewrite, vary headers and internal redirects
>>>
>>>
>>>
>>> Hi everybody,
>>>
>>>
>>>
>>> 2017-10-09 13:46 GMT+02:00 Luca Toscano :
>>>
>>> Hi Yann,
>>>
>>>
>>>
>>> 2017-10-08 14:13 GMT+02:00 Yann Ylavic :
>>>
>>> On Sun, Oct 8, 2017 at 2:03 PM, Yann Ylavic 
>>> wrote:
>>> > Hi Luca,
>>> >
>>> > On Sun, Oct 8, 2017 at 11:59 AM, Luca Toscano 
>>> wrote:
>>> >>
>>> >> Does this approach make sense? Is there any smarter way to do it?
>>> >
>>> > I can't tell that I love the hack in internal redirects but looks like
>>> > a simple way to handle the case...
>>> > Nit: maybe a more descriptive name for the "keep-vary-header" note,
>>> > "redirect-keeps-vary"?
>>>
>>>
>>>
>>> +1
>>>
>>>
>>>
>>>
>>> But after all, if we reach an internal redirect with some Vary header
>>> already set, maybe we should never drop it, thus internal redirects
>>> should preserve Vary in any case...
>>>
>>>
>>>
>>> I'd prefer to limit the scope of the httpd configurations affected by
>>> this change to the minimum, but the change would probably look less hacky :)
>>>
>>>
>>>
>>>
>>>
>>> After https://svn.apache.org/r1811744 trunk should be inline with what
>>> the docs say, but I have another question now: a RewriteCond condition
>>> (containing something like HTTP:someheader) adds a Vary header to the
>>> response only if the condition evaluates to true, meanwhile a 
>>> condition adds the Vary header regardless. Is there any good motivation for
>>> this difference or they should be modified to be more consistent? The 
>>> block behavior seems to be more sound (after reading
>>> https://tools.ietf.org/html/rfc7231#section-7.1.4), but I'd like to
>>> hear more expert opinions :)
>>>
>>>
>>>
>>> Thanks!
>>>
>>>
>>>
>>> Luca
>>>
>>
>>
>

Re: [docs] mod_md documentation clarification

2017-12-02 Thread Luca Toscano 
Hi Rich,

2017-11-28 17:06 GMT+01:00 Stefan Eissing :

>
> > Am 28.11.2017 um 16:40 schrieb Rich Bowen :
> > Related: I also would like to question the wisdom of having a
> ManagedDomain directive and a  container. This will most
> assuredly lead to user confusion and lengthy IRC conversations. I would
> request that the naming of one of these directives be reconsidered. (No,
> I'm not suggesting anything. I suck at naming things.)
>
> I concur that you have more experience in supporting httpd users than
> myself. Personally, I do like it obviously.


I am really interested to follow up this topic, it seems really important
before moving mod_md to 2.4. What are the use cases that you have in mind
about users getting confused? The first one that comes up in my mind is
somebody looking for "ManagedDomain" on a search engine and clicking on the
 link, ending up thinking that only that one exists. And I
can see how this might turn up to be a IRC nightmare, but maybe it could be
resolved with good documentation? I have in mind some changes to add
warnings in both directives, stating very clearly in each one that the
other one also exists, but I am not sure how well this solution could solve
the issue.

The other risk that I can see having something like ManagedDomain and
 (or whatever name we choose) is that users will get
confused while trying to figure out what are the differences between the
two, ending up in IRC again :D

I would also like to get feedback from other people involved in users
support on IRC if possible, this is the right moment to get some wisdom
from them.

Thanks a lot Rich for bringing up this subject!

Luca

Re: apache 2.4.29: mod_http2 stucks from time to time

2017-12-02 Thread Luca Toscano 
Hi everybody,

did I miss an update or are we still waiting for more data? (Don't mean to
rush you Stefan, just to understand what's the status of the thread :)

Luca

2017-11-24 15:26 GMT+01:00 Stefan Priebe - Profihost AG <
s.pri...@profihost.ag>:

> Thanks i‘ll post a log tonight with a 120s stalled request.
>
> Greets,
> Stefan
>
> Excuse my typo sent from my mobile phone.
>
> Am 23.11.2017 um 17:09 schrieb Stefan Eissing <
> stefan.eiss...@greenbytes.de>:
>
> Hey,
>
> could you try the patch below and produce such a lovely log file again?
> H2MaxWorkers please back to before, unconfigured. Thanks! This is a small
> change that a) logs the interaction with h2_workers a bit more and makes
> sure that time gets lost where I think it does. It also switches the fifo
> queue in set mode where duplicate entries are checked, in case that
> interferes here.
>
> Cheers,
>
> Stefan
>
> 
>
>
>
> Am 23.11.2017 um 14:16 schrieb Stefan Priebe - Profihost AG <
> s.pri...@profihost.ag>:
>
>
> Hi,
>
> Am 23.11.2017 um 14:10 schrieb Stefan Eissing:
>
> Interesting. I assume that otherwise this host is the same (OS/CPU etc.)
> as others where it runs without probs?
>
>
> Yes and no i got some more reports by colleagues where they've disabled
>
> http2 as the customers had unexpected long loading times.
>
>
> We are not ghosted by some strange blabla-lake hyper threading thingie
> singularity?
>
>
> Huhoh what's that? Any chance to add some more debugging?
>
>
> Greets,
>
> Stefan
>
>
>
> Need to think about this.
>
>
> Am 23.11.2017 um 13:43 schrieb Stefan Priebe - Profihost AG <
> s.pri...@profihost.ag>:
>
>
> *argh*, i was too fast no it did NOT fix the problem. It even happens with:
>
> H2MaxWorkers4096
>
>
> Sorry about that.
>
>
> Stefan
>
>
> Am 23.11.2017 um 13:42 schrieb Stefan Priebe - Profihost AG:
>
> Hello,,
>
>
> setting:
>
> H2MaxWorkers1024
>
>
> fixes the issue for me. The main problem is how to i know how many
>
> workers are needed? How can i detect whether all workers of h2 are busy?
>
>
> Stefan
>
>
> Am 22.11.2017 um 13:23 schrieb Stefan Priebe - Profihost AG:
>
> Hell Stefan,
>
>
> will send a log to you in a few seconds via private email.
>
>
> Greets,
>
> Stefan
>
>
> Am 21.11.2017 um 23:18 schrieb Stefan Eissing:
>
> sorry for the late reply. for stucks trace2 is best.
>
>
> Am 21.11.2017 um 19:35 schrieb Stefan Priebe - Profihost AG <
> s.pri...@profihost.ag>:
>
>
> Hello Stefan,
>
>
> which loglevel do you need? trace2?
>
>
> Greets,
>
> Stefan
>
>
> Am 21.11.2017 um 16:48 schrieb Stefan Eissing:
>
> Never done this, but https://www.howtoforge.com/setenvif_apache2 seems
> like one way to do make it work.
>
>
> Am 21.11.2017 um 16:16 schrieb Stefan Priebe - Profihost AG <
> s.pri...@profihost.ag>:
>
>
>
> Am 21.11.2017 um 16:06 schrieb Stefan Priebe - Profihost AG:
>
> Am 21.11.2017 um 15:45 schrieb Stefan Eissing:
>
>
> Am 21.11.2017 um 14:33 schrieb Stefan Priebe - Profihost AG <
> s.pri...@profihost.ag>:
>
>
> Hello Stefan,
>
> Hello Yann,
>
>
> me the http2 bug tester is calling again ;-)
>
>
> And the day was going so well...
>
>
> I'm sorry ;-)
>
>
> While running two bash curl while loops the one using http1.1 always
>
> finishes in < 0.05s while the http2 one takes sometimes 0.4 to 20s to
>
> finish. Sadly i can't reproduce this all the time - mostly more requests
>
> more failures. As this is a production server i've no idea how to debug
>
> as the http2 trace logs might flood the harddisk.
>
>
> Hmmm. Do you know if this happens waiting for a response or at the end of
> a connection? Or in the middle of a body? All GETs or also POSTs?
>
>
> My Test only contains GET - but most probably there are also running
>
> POST requests but not started by me.
>
>
> Strangely this only happens between 1pm and 2pm a day but i've no idea
>
> what's different at that time.
>
>
> OK i'm also able to reproduce this whenever your want. Can we activate
>
> trace logging for a specific IP? So i can generate a http2 log?
>
>
>
> I can output a lot of information from curl:
>
>   time_namelookup
>
>   time_connect
>
>time_appconnect
>
>   time_pretransfer
>
>  time_redirect
>
> time_starttransfer
>
>
> Another way might be to enable trace logging only for "my" IP? Is
>
> something like this possible?
>
>
> Greets,
>
> Stefan
>
>
>
>
>
>