[users@httpd] Re: RewriteRule not working, 404 error obtained

[thomas Armstrong]

 I fixed it. I modified "httpd.conf", replacing "AllowOverride None" with
"AllowOverride All" within the "".

On Tue, Jun 28, 2016 at 7:03 PM, thomas Armstrong 
wrote:

> Hi.
>
> Using Apache/2.2.31, I created the following rule on my '.htaccess' file:
> --
> RewriteEngine on
> RewriteRule ^([^/]+)/$ /do.php?label=$1 [L]
> --
>
> However, when accessing 'http://foo.com/whatever/', I get a 404 error
> message. I've checked my error log and:
> ---
> [Mon Jun 27 11:12:15 2016] [error] [client 192.168.1.132] File does not
> exist: /path-to-web/whatever, referer: http://foo.com/
> ---
>
> 'http://foo.com' works ok, and 'http://foo.com/do.php?label=whatever'
> works ok as well.
>
> I've checked phpinfo, and 'mod_rewrite' is loaded in Apache. Additionally,
> I tried to enable it via 'http.conf', but Apache tells me that "module
> rewrite_module is built-in and can't be loaded".
>
> What am I doing wrong? This same '.htaccess' works ok in two other Apache
> servers.
>
> I tried with "Options +FollowSymLinks -MultiViews" as well. Thank you very
> much
>
>

[users@httpd] RewriteRule not working, 404 error obtained

[thomas Armstrong]

Hi.

Using Apache/2.2.31, I created the following rule on my '.htaccess' file:
--
RewriteEngine on
RewriteRule ^([^/]+)/$ /do.php?label=$1 [L]
--

However, when accessing 'http://foo.com/whatever/', I get a 404 error
message. I've checked my error log and:
---
[Mon Jun 27 11:12:15 2016] [error] [client 192.168.1.132] File does not
exist: /path-to-web/whatever, referer: http://foo.com/
---

'http://foo.com' works ok, and 'http://foo.com/do.php?label=whatever' works
ok as well.

I've checked phpinfo, and 'mod_rewrite' is loaded in Apache. Additionally,
I tried to enable it via 'http.conf', but Apache tells me that "module
rewrite_module is built-in and can't be loaded".

What am I doing wrong? This same '.htaccess' works ok in two other Apache
servers.

I tried with "Options +FollowSymLinks -MultiViews" as well. Thank you very
much

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

[Luca Toscano]

2016-06-27 14:52 GMT+02:00 Vacelet, Manuel :

>
>
> On Mon, Jun 27, 2016 at 2:17 PM, Luca Toscano 
> wrote:
>
>>
>>
>> 2016-06-27 13:17 GMT+02:00 Vacelet, Manuel :
>>
>>>
>>>
>>> On Sat, Jun 25, 2016 at 11:00 AM, Luca Toscano 
>>> wrote:
>>>


 2016-06-24 17:26 GMT+02:00 Vacelet, Manuel 
 :

>
>
> On Sun, Jun 19, 2016 at 3:17 PM, Luca Toscano 
> wrote:
>
>>
>>
>> 2016-06-08 16:14 GMT+02:00 Vacelet, Manuel <
>> manuel.vace...@enalean.com>:
>>
>>> On Tue, Jun 7, 2016 at 11:02 PM, Luca Toscano <
>>> toscano.l...@gmail.com> wrote:
>>>


 2016-06-07 10:55 GMT+02:00 Vacelet, Manuel <
 manuel.vace...@enalean.com>:

>
>
> 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 <
>>> toscano.l...@gmail.com> 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