date:20170306

[users@httpd] Re: mod_rewrite behavior when port is specified

2017-03-06 Thread Paul Schroeder

Ah, I see what was going on.  The port being included in the HTTP_HOST var
was causing the initial rewrite to be written as an invalid URL.  It
appears the mod_rewrite was then assuming that this wasn't actually a
redirect and that it needed to prepend the '/' because of this.  I was
distracted by the prepended '/'.  I don't know how I didn't see that
before.  At any rate, here is a solution that works:

RewriteCond %{HTTP_HOST} ^([^:]+):?.*
RewriteRule ^/?(.*) https://%1:443/$1 [R=301,L]

Cheers...Paul..


On Mon, Mar 6, 2017 at 4:18 PM, Paul Schroeder 
wrote:

> Hello..
>
> I'm seeing an issue where mod_rewrite seems to behave differently when the
> client connects to my VirtualHost and includes the port as a part of the
> URL.  i.e.  http://xenial.localdomain vs. http://xenial.localdomain:80
>
> With this RewriteRule, the redirection that I want (to my SSL VirtualHost
> listening on port 443) is working just fine as long as the client uses
> http://xenial.localdomain as the URL:
>
> RewriteRule ^/?(.*) https://%{HTTP_HOST}:443/$1 [R=301,L]
>
> However, when the port is specified ( http://xenial.localdomain:80 ), the
> redirect does not work as expected.  I see the following in my logs:
>
> 192.168.122.1 - - [06/Mar/2017:18:57:58 +] "GET / HTTP/1.1" 301 595
> "-" "Links (2.13; Linux 4.8.13-100.fc23.x86_64 x86_64; GNU C 5.3.1; text)"
> 192.168.122.1 - - [06/Mar/2017:18:57:58 +] "GET /
> https://xenial.localdomain:80:443/ HTTP/1.1" 301 662 "-" "Links (2.13;
> Linux 4.8.13-100.fc23.x86_64 x86_64; GNU C 5.3.1; text)"
> 192.168.122.1 - - [06/Mar/2017:18:57:58 +] "GET /
> https://xenial.localdomain:80:443/https://xenial.
> localdomain:80:443/https://xenial.localdomain:80:443/ HTTP/1.1" 301 798
> "-" "Links (2.13; Linux 4.8.13-100.fc23.x86_64 x86_64; GNU C 5.3.1; text)"
> 192.168.122.1 - - [06/Mar/2017:18:57:58 +] "GET /
> https://xenial.localdomain:80:443/https://xenial.
> localdomain:80:443/https://xenial.localdomain:80:443/
> https://xenial.localdomain:80:443/https://xenial.
> localdomain:80:443/https://xenial.localdomain:80:443/
> https://xenial.localdomain:80:443/ HTTP/1.1" 301 1070 "-" "Links (2.13;
> Linux 4.8.13-100.fc23.x86_64 x86_64; GNU C 5.3.1; text)"
> 192.168.122.1 - - [06/Mar/2017:18:57:58 +] "GET /
> https://xenial.localdomain:80:443/https://xenial.
> localdomain:80:443/https://xenial.localdomain:80:443/
> https://xenial.localdomain:80:443/https://xenial.
> localdomain:80:443/https://xenial.localdomain:80:443/
> https://xenial.localdomain:80:443/https://xenial.
> localdomain:80:443/https://xenial.localdomain:80:443/
> https://xenial.localdomain:80:443/https://xenial.
> localdomain:80:443/https://xenial.localdomain:80:443/
> https://xenial.localdomain:80:443/https://xenial.
> localdomain:80:443/https://xenial.localdomain:80:443/ HTTP/1.1" 301 1614
> "-" "Links (2.13; Linux 4.8.13-100.fc23.x86_64 x86_64; GNU C 5.3.1; text)"
>
> As you can see, a '/' is being prepended to the rewritten URL and
> recursion occurs which eventually causes the URL to become too long and
> cause an error.  Why does specifying the port in the URL cause mod_rewrite
> to behave differently?  Is there a better way for me to do this?
>
> Normally, this wouldn't be an issue, but I need to be able to run this
> VirtualHost on a port other than 80.
>
> Thanks in advance for any suggestions...Paul..
>
>
> ---
>
> Paul B Schroeder 
>



-- 
-- 
---

Paul B Schroeder

[users@httpd] mod_rewrite behavior when port is specified

2017-03-06 Thread Paul Schroeder

Hello..

I'm seeing an issue where mod_rewrite seems to behave differently when the
client connects to my VirtualHost and includes the port as a part of the
URL.  i.e.  http://xenial.localdomain vs. http://xenial.localdomain:80

With this RewriteRule, the redirection that I want (to my SSL VirtualHost
listening on port 443) is working just fine as long as the client uses
http://xenial.localdomain as the URL:

RewriteRule ^/?(.*) https://%{HTTP_HOST}:443/$1 [R=301,L]

However, when the port is specified ( http://xenial.localdomain:80 ), the
redirect does not work as expected.  I see the following in my logs:

192.168.122.1 - - [06/Mar/2017:18:57:58 +] "GET / HTTP/1.1" 301 595 "-"
"Links (2.13; Linux 4.8.13-100.fc23.x86_64 x86_64; GNU C 5.3.1; text)"
192.168.122.1 - - [06/Mar/2017:18:57:58 +] "GET
/https://xenial.localdomain:80:443/ HTTP/1.1" 301 662 "-" "Links (2.13;
Linux 4.8.13-100.fc23.x86_64 x86_64; GNU C 5.3.1; text)"
192.168.122.1 - - [06/Mar/2017:18:57:58 +] "GET
/https://xenial.localdomain:80:443/https://xenial.localdomain:80:443
/https://xenial.localdomain:80:443/ HTTP/1.1" 301 798 "-" "Links (2.13;
Linux 4.8.13-100.fc23.x86_64 x86_64; GNU C 5.3.1; text)"
192.168.122.1 - - [06/Mar/2017:18:57:58 +] "GET
/https://xenial.localdomain:80:443/https://xenial.localdomain:80:443
/https://xenial.localdomain:80:443/https://xenial.localdomain:80:443
/https://xenial.localdomain:80:443/https://xenial.localdomain:80:443
/https://xenial.localdomain:80:443/ HTTP/1.1" 301 1070 "-" "Links (2.13;
Linux 4.8.13-100.fc23.x86_64 x86_64; GNU C 5.3.1; text)"
192.168.122.1 - - [06/Mar/2017:18:57:58 +] "GET
/https://xenial.localdomain:80:443/https://xenial.localdomain:80:443
/https://xenial.localdomain:80:443/https://xenial.localdomain:80:443
/https://xenial.localdomain:80:443/https://xenial.localdomain:80:443
/https://xenial.localdomain:80:443/https://xenial.localdomain:80:443
/https://xenial.localdomain:80:443/https://xenial.localdomain:80:443
/https://xenial.localdomain:80:443/https://xenial.localdomain:80:443
/https://xenial.localdomain:80:443/https://xenial.localdomain:80:443
/https://xenial.localdomain:80:443/ HTTP/1.1" 301 1614 "-" "Links (2.13;
Linux 4.8.13-100.fc23.x86_64 x86_64; GNU C 5.3.1; text)"

As you can see, a '/' is being prepended to the rewritten URL and recursion
occurs which eventually causes the URL to become too long and cause an
error.  Why does specifying the port in the URL cause mod_rewrite to behave
differently?  Is there a better way for me to do this?

Normally, this wouldn't be an issue, but I need to be able to run this
VirtualHost on a port other than 80.

Thanks in advance for any suggestions...Paul..


---

Paul B Schroeder

Re: [users@httpd] Help with rewriterule

2017-03-06 Thread Robert Moskowitz


Luca,

Thank you for replying.

On 03/06/2017 04:07 AM, Luca Toscano wrote:

Hi Robert,

2017-03-05 21:57 GMT+01:00 Robert Moskowitz >:


Hello,

This is for Apache 2.4 on Centos7.  I am migrating from Apache 2.2
on Centos6.

I want to support redirecting all webmail queries to https.  for
either queries to:

webmail.foo.com  or foo.com/webmail


My old rules were:


ServerName webmail.htt-consult.com

ServerAlias webmail
RewriteEngine On
RewriteCond  %{SERVER_PORT} !^443$
RewriteRule ^.*$ https://%{SERVER_NAME}%{REQUEST_URI} [L,R]
ExpiresDefault "access plus 10 years"
AddOutputFilterByType DEFLATE text/html text/plain text/xml
php_admin_flag session.cookie_secure "1"


This SEEMED to only work for the webmail virtual host, and not
others on this server.  When I used this rule set on the new
server, it clearly was redirecting all web accesses to https. 



Have you checked if the VirtualHost is the default one (you can use 
apachectl -S to confirm)?


Comes back  response.


So I tried to write a more restrictive rule, trying to follow
instructions from

http://httpd.apache.org/docs/current/rewrite/intro.html


It would seem the rule:

RewriteRule ^.*webmail
https://%{SERVER_NAME}%{REQUEST_URI} [L,R]

Should work, but the test site I tried:

http://martinmelin.se/rewrite-rule-tester/


Did not show this did the rewrite to https. 



So from 
http://httpd.apache.org/docs/current/mod/mod_rewrite.html#rewriterule:


"RewriteRule Pattern Substitution [flags]"
"In VirtualHost context, The Pattern will initially be matched against 
the part of the URL after the hostname and port, and before the query 
string (e.g. "/app1/index.html"). This is the (%-decoded) URL-path."
If I got it correctly you are trying to match the hostname in the 
Pattern, that shouldn't work in Vhost context.


Also how to direct Webmail.foo.com  to
https://webmail.foo.com?


https://httpd.apache.org/docs/2.4/mod/mod_alias.html#redirect or 
https://httpd.apache.org/docs/2.4/mod/mod_alias.html#redirectmatch 
might help you (and in my opinion they are way more maintainable than 
rewrite rules).



RedirectMatch ^.*webmail https://%{SERVER_NAME}%{REQUEST_URI} [L,R]

But how do I get this NOT to redirect when it is already https:// ?
And how do I handle Webmail as well as webmail?  Would that be

RedirectMatch ^.*[wW]ebmail https://%{SERVER_NAME}%{REQUEST_URI} [L,R]

thanks

Re: [users@httpd] httpd 2.4.25-1.fc25 avoiding search permission errors across file systems Fedora 25 linux

2017-03-06 Thread David B Snyder


Thanks, this seems to have worked!

I guess I need to learn about SELinux now. :)


On 03/05/2017 06:04 PM, Robert Moskowitz wrote:

Are you running SELinux?

Have you done the needed:

chcon -R -t httpd_sys_content_rw_t /diretory

commands?

On 03/05/2017 05:48 PM, David B Snyder wrote:
I am trying to set up httpd across several file systems on a Fedora 
25 Linux

 system, and I'm doing something wrong.

I haven't succeeded in getting httpd to serve pages across the 
mounted file systems.


example errors:
[Sun Mar 05 13:31:50.628070 2017] [core:error] [pid 1001] 
(13)Permission denied: [client ::1:50082] AH00035: access to 
/snyder/index.html denied (filesystem path 
'/mnt/Workspace/snyder/www/index.html') because search permissions 
are missing on a component of the path


[Sun Mar 05 13:32:01.840581 2017] [core:error] [pid 999] 
(13)Permission denied: [client ::1:50084] AH00035: access to 
/local/index.html denied (filesystem path '/home/snyder/index.html') 
because search permissions are missing on a component of the path



As far as I can tell, the permissions are correct, allowing read and 
execute

drwxr-xr-x.  14 root   root4096 Feb  3 09:51 /mnt #this works

drwxr-xr-x. 6 root root  4096 Mar  4 15:55 /mnt/Workspace  #does not 
work

drwxr-xr-x.   9 snyder snyder  4096 Dec  9 10:31 /home #does not work

From httpd.conf:
...


Options Indexes FollowSymLinks
AllowOverride None
# Allow open access:
Require all granted



Options Indexes FollowSymLinks
AllowOverride None
# Allow open access:
Require all granted



Options Indexes FollowSymLinks
AllowOverride None
# Allow open access:
   Require all granted



alias /local/ /home/snyder/
alias /mnt/ /mnt/
alias /snyder/ /mnt/Workspace/snyder/www/

...

From my browser [Firefox]
'localhost'  displays the index.html

'localhost/mnt/' produces a directory listing, however clicking on the
Workspace entry [localhost/mnt/Workspace] produces 403 "Forbidden /n
You don't have permission to access /mnt/Workspace/ on this server."

'localhost/local/' produces a similar 403 "Forbidden" message.

The error_log messages are

[Sun Mar 05 13:31:50.628070 2017] [core:error] [pid 1001] 
(13)Permission denied: [client ::1:50082] AH00035: access to 
/snyder/index.html denied (filesystem path 
'/mnt/Workspace/snyder/www/index.html') because search permissions 
are missing on a component of the path


[Sun Mar 05 14:07:25.405553 2017] [autoindex:error] [pid 1000] 
(13)Permission denied: [client ::1:50688] AH01275: Can't open 
directory for index: /mnt/Workspace/, referer: http://localhost/mnt/



from /etc/mtab:
/dev/sda6 /mnt/Workspace ext4 rw,seclabel,relatime,data=ordered 0 0
/dev/mapper/fedora_snydercpu-home /home ext4 
rw,seclabel,relatime,data=ordered 0 0


I'm running Fedora 25 with
httpd.x86_64 2.4.25-1.fc25   @updates
httpd-filesystem.noarch 2.4.25-1.fc25   @updates
httpd-manual.noarch 2.4.25-1.fc25   @updates
httpd-tools.x86_64 2.4.25-1.fc25   @updates

I suppose I could work exclusively within the root file system, But I 
think I

should not have to :).

Thanks for any advice

-David Snyder






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




--
dbsnyder471 (at) gmail.com


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

Re: [users@httpd] mod_lua and subprocess_env

2017-03-06 Thread Yann Ylavic

Hi Andrei,

On Mon, Mar 6, 2017 at 10:15 AM, Andrei Ivanov 
wrote:

> On Thu, Mar 2, 2017 at 12:40 PM, Andrei Ivanov 
> wrote:
>
>> On Tue, Feb 28, 2017 at 12:09 PM, Andrei Ivanov 
>> wrote:
>>
>>> On Mon, Feb 27, 2017 at 11:58 AM, Andrei Ivanov >> > wrote:
>>>
 On Fri, Feb 24, 2017 at 10:58 PM, Andrei Ivanov <
 andrei.iva...@gmail.com> wrote:

> On Feb 24, 2017 22:54, "Yann Ylavic"  wrote:
>
> On Fri, Feb 24, 2017 at 6:50 PM, Andrei Ivanov <
> andrei.iva...@gmail.com> wrote:
> >
> > I've managed to apply your patch and rebuild Apache and now I have:
> > Header set Client-IP "expr=%{REMOTE_ADDR}"
> > Header set Client-SAN "expr=%{PeerExtList:2.5.29.17}"
> > Header set Client-DN "expr=%{SSL_CLIENT_S_DN}"
>
> Could you please add:
>   Header set Expr "'IP Address:'.%{REMOTE_ADDR} -in
> PeerExtList('2.5.29.17')"
> ?
>
> If it outputed "Expr: IP Addressfalse" that'd be issue with operators'
> precedence.
> I'll try on my side, but you may beat me to it since you have the
> environment...
>
>
> Ugh, it's my work environment, I'll be able to access it only on
> Monday.
>
>
 Tried now, I've adapted your suggestion a bit as it doesn't seem
 correct:

 Header set Expr "expr='IP Address:'.%{REMOTE_ADDR} -in
 %{PeerExtList:2.5.29.17}"

 This results in:
 Expr: 'IP Address:'.159.107.78.127 -in email:,
 email:, IP Address:127.0.0.1, IP Address:0:0:0:0:0:0:0:1, IP
 Address:159.107.78.127, IP Address:FE80:0:0:0:6D03:4CE1:C15F:5A44

 As far as I understand, it doesn't perform the concatenation properly.
 I've tried
 Header set Expr "expr='%{IP Address:'
 
 .%{REMOTE_ADDR}} -in %{PeerExtList:2.5.29.17}"

 But I get a parse error at startup:
 Can't parse value expression : syntax error, unexpected T_ERROR,
 expecting T_VAR_END or ':': Invalid character in variable name ' '

 But I think mod_headers has some different way of interpreting
 expressions, because this doesn't work:

 Header set matched false
 >>> 
 %{PeerExtList:2.5.29.17}">
 Header set matched true
 

 Cannot parse condition clause: syntax error, unexpected T_VAR_BEGIN,
 expecting T_ID or '{

>>>
>>> Yann? Any clues? :-)
>>>
>>
>> Ping 
>>
>
> Hello?
>

Yes sorry, was busy these days ;)

Mixing different types (string, boolean, list) of expressions is not
working currently, and requires changes in the parser (I'll try to work on
this soon).

In the meantime, maybe with my patch you could try to (uglily) match
"%{PeerExtList:2.5.29.17}" (as a string, hence with the operator "~=")
against something like "IP Address:".%{REMOTE_ADDR}(,|$) ?


Regards,
Yann.

Re: [users@httpd] mod_lua and subprocess_env

2017-03-06 Thread Andrei Ivanov

On Thu, Mar 2, 2017 at 12:40 PM, Andrei Ivanov 
wrote:

> On Tue, Feb 28, 2017 at 12:09 PM, Andrei Ivanov 
> wrote:
>
>> On Mon, Feb 27, 2017 at 11:58 AM, Andrei Ivanov 
>> wrote:
>>
>>> On Fri, Feb 24, 2017 at 10:58 PM, Andrei Ivanov >> > wrote:
>>>
 On Feb 24, 2017 22:54, "Yann Ylavic"  wrote:

 On Fri, Feb 24, 2017 at 6:50 PM, Andrei Ivanov 
 wrote:
 >
 > I've managed to apply your patch and rebuild Apache and now I have:
 > Header set Client-IP "expr=%{REMOTE_ADDR}"
 > Header set Client-SAN "expr=%{PeerExtList:2.5.29.17}"
 > Header set Client-DN "expr=%{SSL_CLIENT_S_DN}"

 Could you please add:
   Header set Expr "'IP Address:'.%{REMOTE_ADDR} -in
 PeerExtList('2.5.29.17')"
 ?

 If it outputed "Expr: IP Addressfalse" that'd be issue with operators'
 precedence.
 I'll try on my side, but you may beat me to it since you have the
 environment...


 Ugh, it's my work environment, I'll be able to access it only on
 Monday.


>>> Tried now, I've adapted your suggestion a bit as it doesn't seem correct:
>>>
>>> Header set Expr "expr='IP Address:'.%{REMOTE_ADDR} -in
>>> %{PeerExtList:2.5.29.17}"
>>>
>>> This results in:
>>> Expr: 'IP Address:'.159.107.78.127 -in email:,
>>> email:, IP Address:127.0.0.1, IP Address:0:0:0:0:0:0:0:1, IP
>>> Address:159.107.78.127, IP Address:FE80:0:0:0:6D03:4CE1:C15F:5A44
>>>
>>> As far as I understand, it doesn't perform the concatenation properly.
>>> I've tried
>>> Header set Expr "expr='%{IP Address:'.%{REMOTE_ADDR}} -in
>>> %{PeerExtList:2.5.29.17}"
>>>
>>> But I get a parse error at startup:
>>> Can't parse value expression : syntax error, unexpected T_ERROR,
>>> expecting T_VAR_END or ':': Invalid character in variable name ' '
>>>
>>> But I think mod_headers has some different way of interpreting
>>> expressions, because this doesn't work:
>>>
>>> Header set matched false
>>> 
>>> Header set matched true
>>> 
>>>
>>> Cannot parse condition clause: syntax error, unexpected T_VAR_BEGIN,
>>> expecting T_ID or '{
>>>
>>
>> Yann? Any clues? :-)
>>
>
> Ping 
>

Hello?

Re: [users@httpd] Help with rewriterule

2017-03-06 Thread Luca Toscano

Hi Robert,

2017-03-05 21:57 GMT+01:00 Robert Moskowitz :

> Hello,
>
> This is for Apache 2.4 on Centos7.  I am migrating from Apache 2.2 on
> Centos6.
>
> I want to support redirecting all webmail queries to https.  for either
> queries to:
>
> webmail.foo.com or foo.com/webmail
>
> My old rules were:
>
> 
> ServerName webmail.htt-consult.com
> ServerAlias webmail
> RewriteEngine On
> RewriteCond  %{SERVER_PORT} !^443$
> RewriteRule ^.*$ https://%{SERVER_NAME}%{REQUEST_URI} [L,R]
> ExpiresDefault "access plus 10 years"
> AddOutputFilterByType DEFLATE text/html text/plain text/xml
> php_admin_flag session.cookie_secure "1"
> 
>
> This SEEMED to only work for the webmail virtual host, and not others on
> this server.  When I used this rule set on the new server, it clearly was
> redirecting all web accesses to https.


Have you checked if the VirtualHost is the default one (you can use
apachectl -S to confirm)?


> So I tried to write a more restrictive rule, trying to follow instructions
> from
>
> http://httpd.apache.org/docs/current/rewrite/intro.html
>
> It would seem the rule:
>
> RewriteRule ^.*webmail https://%{SERVER_NAME}%{REQUEST_URI} [L,R]
>
> Should work, but the test site I tried:
>
> http://martinmelin.se/rewrite-rule-tester/
>
> Did not show this did the rewrite to https.


So from
http://httpd.apache.org/docs/current/mod/mod_rewrite.html#rewriterule:

"RewriteRule Pattern Substitution [flags]"
"In VirtualHost context, The Pattern will initially be matched against the
part of the URL after the hostname and port, and before the query string
(e.g. "/app1/index.html"). This is the (%-decoded) URL-path."

If I got it correctly you are trying to match the hostname in the Pattern,
that shouldn't work in Vhost context.

Also how to direct Webmail.foo.com to https://webmail.foo.com?
>

https://httpd.apache.org/docs/2.4/mod/mod_alias.html#redirect or
https://httpd.apache.org/docs/2.4/mod/mod_alias.html#redirectmatch might
help you (and in my opinion they are way more maintainable than rewrite
rules).

Hope that helps!

Luca

[users@httpd] Re: mod_rewrite behavior when port is specified

[users@httpd] mod_rewrite behavior when port is specified

Re: [users@httpd] Help with rewriterule

Re: [users@httpd] httpd 2.4.25-1.fc25 avoiding search permission errors across file systems Fedora 25 linux

Re: [users@httpd] mod_lua and subprocess_env

Re: [users@httpd] mod_lua and subprocess_env

Re: [users@httpd] Help with rewriterule

7 matches

Site Navigation

Mail list logo

Footer information