Re: [users@httpd] mod proxy hcheck not observing timeout value

[Codeweavers]

Hi Daniel,

We initially had trouble as this patch seems from our testing to require
the timeout value set on the BalancerMember line of the configuration,
which to us was not immediately obvious (many parts of the configuration
seem to take a timeout that from the documents seem like it would
represent the same setting), though looking at the code that is patched and
the documentation I can see that the BalancerMember lines do represent
workers which I presume corresponds with the worker object code looks to be
pulling the value from.

Kind regards

Ben

On Thu, 17 Nov 2022 at 18:35, Daniel Ferradal  wrote:

> Hello,
>
> I initially reported this in April 2021 and @Yann Ylavic quickly made a
> patch out of it. I am not sure why it didn't make it.
>
> You can see the conversation here for reference:
>
> https://httpd.markmail.org/message/xteh3uw53inl25gx?q=mod_proxy_hcheck+response+timeout%3F
>
> I also agree it is a good patch and although I initially had issues with
> it it was probably due to some problem on my part.
>
> Your confirmation may be good enough to validate it and propose it for
> next release perhaps?
>
> Thanks for bringing this back.
>
> Cheers
>
>
>
> El jue, 17 nov 2022 a las 17:26, Benjamin Davis (<
> benjaminda...@codeweavers.net>) escribió:
>
>> Hey All,
>>
>> we have apache2 2.4.54 setup as a load balancer for our IIS backend
>> servers. We would like to be able to carry out health checks using
>> mod_proxy_hcheck and check that the backend server is serving a webpage. We
>> have successfully set this up however in the event that a health check
>> request to the backend hangs, apache never reaches a timeout and therefore
>> the healthcheck doesn't fail.
>>
>> We have found a commit
>> https://github.com/apache/httpd/commit/ab2b9dbfb74049ad207a91c45971948127dde893
>>  that
>> fixes this issue, we have verified this by building apache with this change
>> applied and confirmed that when a timeout is provided in the apache
>> balancer configuration, specifically on the BalancerMember line, the
>> healthcheck(s) will timeout and put the backend into a failed state.
>>
>> This code is not in the latest apache release, does anyone have any idea
>> if this will be part of a future release? Or can advise regarding this
>> issue.
>>
>> Many thanks
>>
>> Ben
>>
>> --
>>
>> Ben Davis
>>
>> Infrastructure Engineer
>>
>>
>> Website: www.codeweavers.net
>>
>>
>>
>>
>>
>> Barn 4, Dunston Business Village, ST18 9AB. Registered in England and
>> Wales
>>
>> No. 04092394 VAT registration no. 974 9705 63
>>
>>
>>
>
> --
> Daniel Ferradal
> HTTPD Project
> #httpd help at Libera.Chat
>

-- 

[users@httpd] Bug? LDAPRetryDelay from mod_ldap uses the wrong unit

[Stephen Blott]

Hi,

I'm not sure what to do with this.  Help would be appreciated.

It's an apparent bug in mod_ldap relating to the LDAPRetryDelay option:
   https://httpd.apache.org/docs/2.4/mod/mod_ldap.html#ldapretrydelay

Issue:
  LDAP configuration option LDAPRetryDelay...

  The Documentation suggests that the unit is seconds:
https://httpd.apache.org/docs/2.4/mod/mod_ldap.html#ldapretrydelay

  The code suggests that the unit is microseconds (see code chase, below).

Effect:
  Apache sometimes issues a burst of almost simultaneous LDAP search/bind
  requests.

  (In my organisation, this is "catastrophic" since, if the password is
   incorrect, it appears as N failed login attempts, and the account is
   instantly blocked (after just a single attempt). In practice,
   I've observed N in the region of 5 to 7.)

Configuration option:

  LDAPRetryDelay 5   (for example)

  This sets the retry delay for LDAP connections.

  In the code, this ends up here...

In util_ldap_set_retry_delay (util_ldap.c:2859):

  st->retry_delay = timeout;

  Note... no unit conversion takes place; the code just checks that it's
  a non-negative integer and notes the value for later.

The delay is implemented in httpd/modules/ldap/util_ldap.c:668:

  apr_sleep(st->retry_delay);

  Note... we still appear to have the raw value from the configuration
  file (nominally in seconds).

If you search the code, you will find that apr_sleep() is *almost always*
called like this:

  apr_sleep(apr_time_from_sec())

  That is, the unit expected is whatever is returned by apr_time_from_sec().

In APR, apr_time_from_sec() is defined like this (apr/include/apr_time.h):

  /** number of microseconds per second */
  #define APR_USEC_PER_SEC APR_TIME_C(100)

  .
  .
  .

  /** @return seconds as an apr_time_t */
  #define apr_time_from_sec(sec) ((apr_time_t)(sec) * APR_USEC_PER_SEC)

  So, the result of apr_time_from_sec is in microseconds.

It looks like the documentation is in seconds, but the implementation is in
microseconds.

Is my analysis correct?

What do I do next?

Thanks for reading.

Steve
--
  Stephen Blott
  Students... contact me on Slack: https://slack.computing.dcu.ie/
  Staff... contact me on Slack: https://dcucommunity.slack.com/
  Vanity Zoom room: https://dcu-ie.zoom.us/my/smblott
  Rm: L1.02
  School of Computing
  Dublin City University, Glasnevin, Dublin, Ireland

-- 
*

*Séanadh Ríomhphoist/Email Disclaimer*

*Tá an ríomhphost seo agus aon 
chomhad a sheoltar leis faoi rún agus is lena úsáid ag an seolaí agus sin 
amháin é. Is féidir tuilleadh a léamh anseo.  
*

*This e-mail and any 
files transmitted with it are confidential and are intended solely for use 
by the addressee. Read more here. 
*



*

-- 

   
 
 
 

AW: [users@httpd] OCSP Stapling Logs with mod_md

[simon.studer]

Hi Daniel,

Thanks for your reply.

Yes, mod_ssl does offer OCSP stapling capabilities 
(https://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslocspenable), however, we 
use the OCSP stapling implementation provided by mod_md 
(https://httpd.apache.org/docs/2.4/mod/mod_md.html#mdstapling).

That is why the info is available in job.json but unfortunately, the same info 
does not appear to be available in mod_md logs, even at higher log levels.

Best,
Simon


-Ursprüngliche Nachricht-
Von: Daniel Ferradal  
Gesendet: Donnerstag, 17. November 2022 19:39
An: users@httpd.apache.org
Betreff: Re: [users@httpd] OCSP Stapling Logs with mod_md

Isn't OCSP and everything related to it directly related to mod_ssl?

When you say it was not in the error log, do you mean LogLevel
ssl:trace7 or which configuration did you have to try and get logs about this?

El vie, 9 sept 2022 a las 9:15,  escribió:
>
> Hi everyone,
>
>
>
> We recently had issues renewing OCSP information with mod_md for Certificates 
> not managed by mod_md. The issue was not related to mod_md and there was no 
> interruption since the OCSP information is cached.
>
>
>
> While analyzing the issue, we noticed that even at high log levels some 
> information was not being logged in the Apache error log but only in mod_md’s 
> own job.json.
>
>
>
> Note that while it contains valuable information, job.json is complicated to 
> forward to centralized log servers because of its format.
>
>
>
> Is there any way to have these entries logged in the error log as well?
>
>
>
> Also, could the information in job.json be accessed over /md-status even when 
> there are no mod_md-managed certificates (currently the response only 
> contains the mod_md version string)?
>
>
>
> Thanks!
>
> Simon



--
Daniel Ferradal
HTTPD Project
#httpd help at Libera.Chat

-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org

[users@httpd] Problems with cache in many browsers

[Erick Castaneda Martinez1]

Hi!


We are currently facing some problems related with browser cache.  The browsers 
(Opera, Firefox and Chrome; Windows 11) are not showing the right content of a 
web application. We are making some tests switching between the old static 
files (html, css, js) of the project and the new files, but the problem 
persists.


By the time we have tried changing some settings in the httpd.conf file. The 
first option we tried was to add the following settings to mod_rewrite


   #Initialize mod_rewrite
   RewriteEngine On
   
 FileETag None
 
   Header unset ETag
   Header set Cache-Control "max-age=0, no-cache, no-store, must-revalidate"
   Header set Pragma "no-cache"
   Header set Expires "Wed, 12 Jan 1980 05:00:00 GMT"
 
   

RequestHeader unset If-Modified-Since
RequestHeader unset If-None-Match
   



Then we tried with the mod_expires tag with the following setting


ExpiresActive On
ExpiresByType image/png "access plus 3 seconds"
ExpiresByType image/gif "access plus 3 seconds"
ExpiresByType image/jpeg "access plus 3 seconds"
ExpiresByType text/javascript "access plus 3 seconds"
ExpiresByType text/css "access plus 3 seconds"
ExpiresByType text/html "access plus 3 seconds"
ExpiresDefault "access plus 3 seconds"



The problem here is that we are not having a consistent behavior across 
settings. For example, in some tests with one configuration, the web browsers 
are showing the right website instantly, then, after changing the static files 
with the exact same configuration, the web browsers show a wrong version.


Is there some aditional settings to be set o there is something else are we 
missing?