Re: [users@httpd] Re: CLOSED - Re: [users@httpd] Macros + Require constructs

[Marat Khalili]

On 18/06/16 22:03, John Allen wrote:
Interestingly, without the RequireAll around the "Require user %user" 
it does not work.


Sounds like a bug?

--

With Best Regards,
Marat Khalili


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

Re: [users@httpd] mod_proxy and DNS resolving

[Luca Toscano]

2016-05-28 12:25 GMT+02:00 Luca Toscano :

> Hi Yann,
>
> 2016-05-28 0:31 GMT+02:00 Yann Ylavic :
>
>> Hi Luca,
>>
>> On Mon, May 23, 2016 at 2:21 PM, Luca Toscano 
>> wrote:
>> >
>> > I replied to the comment that you pointed out with Jim's answer and I
>> > updated the trunk documentation with a note about DNS resolution:
>> >
>> > http://httpd.apache.org/docs/trunk/mod/mod_proxy.html#workers
>> >
>> > HTML diff only:
>> >
>> http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/mod/mod_proxy.html.en?r1=1745170=1745169=1745170
>>
>> I don't think this is correct.
>> When disablereuse is true (including the default workers), the DNS
>> resolution occurs for each connection.
>> But when mod_proxy is reusing connections (including addresses), each
>> worker/backend address is resolved only once per child process, and
>> reused for all further connections (until the child is recycled).
>> AIUI, this is not related to the TTL.
>>
>
>
> Thanks a lot for the explanation and for the info. So httpd does cache
> origin DNS resolution and there is no way to control it via mod-proxy
> settings (maybe the only thing that could be used
> is MaxConnectionsPerChild?).
>
>
>>
>> From ap_proxy_determine_connection():
>> /*
>>  * Worker can have the single constant backend adress.
>>  * The single DNS lookup is used once per worker.
>>  * If dynamic change is needed then set the addr to NULL
>>  * inside dynamic config to force the lookup.
>>  */
>> AFAICT, nothing sets "addr to NULL" anywhere in httpd, that would be
>> racy anyway.
>>
>> There is indeed a worker 'is_address_reusable' flag distinct from
>> 'disablereuse', but it is not exposed to the admin and seems to be
>> internally mapped to 'disablereuse'.
>>
>> I have a patch which introduces 'addressTTL' if one is interested, but
>> it's not that simple because it addresses the race locklessly (and
>> leaklessly :), thus with refcounting, address pool...
>>
>>
> If I got everything correctly, the description of the TTL might be a bit
> misleading because it is not clear IMHO that the DNS resolution won't be
> performed:
>
> "Time to live for inactive connections and associated connection pool
> entries, in seconds. Once reaching this limit, a connection will not be
> used again; it will be closed at some later time."
>
> What would happen when an admin performs a change of the origin DNS A or
>  record? If httpd doesn't happen to recycle workers at that time it
> will try to connect to the old IP address probably triggering a 502 due to
> timeouts or connection failures right?
>
> The perfect thing, IMHO, would be to force the DNS resolution every time a
> new connection to origin needs to be performed (transparently to all the
> options), but as you mentioned the implementation could be messy and I am
> not sure how many people would like this feature.
>
> Anyhow, I'll wait for some replies to check that I got everything
> correctly and then I'll updated the documentation (unless somebody wants to
> do it before me).
>
>
FYI for the interested readers: I fixed trunk's documentation following
Yann's advice with http://svn.apache.org/r1748948
Will do more tests and then in case I'll backport it to the 2.4 doc. The
HTML now says:

"DNS resolution happens when the socket to the origin domain is created for
the first time. When connection pooling is used, each backend domain is
resolved only once per child process, and reused for all further
connections until the child is recycled. This information should to be
considered while planning DNS maintenance tasks involving backend domains."

Any feedback will be really welcome!

Luca

Re: [users@httpd] Last-Modified header overridden

[Luca Toscano]

2016-06-08 16:14 GMT+02:00 Vacelet, Manuel :

> On Tue, Jun 7, 2016 at 11:02 PM, Luca Toscano 
> wrote:
>
>>
>>
>> 2016-06-07 10:55 GMT+02:00 Vacelet, Manuel :
>>
>>>
>>>
>>> On Mon, Jun 6, 2016 at 5:32 PM, Vacelet, Manuel <
>>> manuel.vace...@enalean.com> wrote:
>>>
 dOn Mon, Jun 6, 2016 at 5:00 PM, Vacelet, Manuel <
 manuel.vace...@enalean.com> wrote:

> On Mon, Jun 6, 2016 at 4:09 PM, Luca Toscano 
> wrote:
>
>>
>> I was able to repro building httpd from 2.4.x branch and following
>> your configuration files on github. I am almost sure that somewhere httpd
>> sets the Last-Modified header translating "foo" to the first Jan 1970 
>> date.
>> I realized though that I didn't recall the real issue, since passing 
>> value
>> not following the RFC can lead to inconsistencies, so I went back and
>> checked the correspondence. Quoting:
>>
>> "Actually I wrote this snippet to highlight the behaviour (the
>> original code sent the date in iso8601 instead of rfc1123) because it was
>> more obvious.
>> During my tests (this is extracted from an automated test suite),
>> even after having converted dates to rfc1123, I continued to get some
>> sparse errors. What I got is that the value I sent was sometimes slightly
>> modified (a second or 2) depending on the machine load."
>>
>> So my understanding is that you would like to know why a
>> Last-Modified header with a legitimate date/time set by a PHP app gets
>> "delayed" by a couple of seconds from httpd, right?
>>
>
> Yes for sure, this is the primary issue.
> However, the (undocumented) difference of behavior from one version to
> another (2.2 -> 2.4 and more surprisingly from between two 2.4 versions) 
> is
> also in question here.
> Even more strange, 2.4 built for other distrib doesn't highlight the
> behaviour !
>
>

 I made another series of test and it seems to be linked to fastcgi.

 I took the stock apache (2.4.6 plus tons of patches)  & php-fpm (5.4.16
 + tons of patches) from RHEL7 and I get the exact same behaviour (headers
 rewritten to EPOCH)
 However, if I server the very same php script from mod_php (instead of
 fcgi) it "works" (the headers are not modified).


>>> For the record, I also have the same behaviour (headers rewritten when
>>> using php-fpm + fastcgi) on alpine linux 3.4 that ships apache2-2.4.20.
>>> So AFAICT, it doesn't seem distro specific.
>>>
>>> On the root of the problem, from my point of view:
>>> - the difference between mod_php vs. php-fpm + fcgi is understandable
>>> (even if not desired and not documented).
>>> - the fact that fcgi handler parse & rewrite headers seems to lead to
>>> inconsistencies (I'll try to build a test case for that).
>>> - however, even if the headers are wrong, I think apache default (use
>>> EPOCH) is wrong as it leads to very inconsistent behaviour (the resource
>>> will never expire). I would prefer either:
>>> -- do not touch the header
>>> -- raise a warning and discard the header
>>>
>>> What do you think ?
>>>
>>
>>
>> From my tests the following snippet of code should be responsible for the
>> switch from 'foo' to unix epoch:
>>
>> *https://github.com/apache/httpd/blob/2.4.x/server/util_script.c#L663
>> *
>>
>> The function that contains the code, ap_scan_script_header_err_core_ex,
>> is wrapped by a lot of other functions eventually called by modules like
>> mod-proxy-fcgi. A more verbose description of the function in:
>>
>> https://github.com/apache/httpd/blob/2.4.x/include/util_script.h#L200
>>
>> Not sure what would be the best thing to do, but probably we could follow
>> up in a official apache bugzilla task?
>> https://bz.apache.org/bugzilla/enter_bug.cgi?product=Apache%20httpd-2
>>
>>
> Wow, thanks for the investigation !
>

Sorry for the delay! I submitted a patch for trunk with a possible fix,
namely dropping (and logging at trace1 level) any non compliant date/time
set in a Last-Modified header returned by a FCGI/CGI script:
http://svn.apache.org/r1748379

The fix is also in the list of proposal for backport to the 2.4.x branch,
we'll see what other people think about this solution.

We should also do a follow up for the other main issue, namely the fact
that you see a different/delayed Last-Modified header sometimes among your
FCGI/httpd responses. Can you give me an example of Last-Modified header
value before/after the "delay" and a way to repro it?

Thanks!

Luca