Re: [users@httpd] SSI / .shtml expressions /
Okay, thanks. It isn’t that important for me to get the SSILegacyExprParser off if it’s already on in my configuration. I don’t have access to WHM. But if the SSILegacyExprParser is on for me, why won’t this work?: Shouldn’t it, if the legacy syntax is on? /Simen Fra: Yehuda Katz Sendt: mandag, 15. september 2014 18:59 Til: users@httpd.apache.org This might be better on a cPanel forum, since it seems that Apache is working as expected. If you have access to WHM, you could modify /var/cpanel/templates/apache2_4/vhost.default to remove the "SSILegacyExprParser On" and rebuild your config (/usr/local/cpanel/bin/build_apache_conf). - Y On Mon, Sep 15, 2014 at 12:26 PM, Simen Mangseth wrote: I’ve copied that code into .htaccess (with the sitename change, of course), but it doesn’t appear to have an effect. Maybe you could use the live sites to find out if there’s anything wrong with them? http://dd.no/404.shtml http://dans.no/404.shtml http://ddcountry.no/404.shtml http://gullskoen.no/404.shtml The 4 are identical, but should have a different color text and logo. It doesn’t as of now, at least not in my browser or PC. I know I have the newest Apache. I don’t know where the fault is. Really frustrating that this code works with you, and nothing works on my site. Fra: Yehuda Katz Sendt: mandag, 15. september 2014 18:06 Til: users@httpd.apache.org Except for the one "$side = ddcountry" which you missed converting... On Mon, Sep 15, 2014 at 12:03 PM, Yehuda Katz wrote: EasyApache is the cPanel program that builds the Apache (and PHP) binaries and config files, so if you use cPanel, you use EasyApache. I looked on my cPanel server and found this directive: SSILegacyExprParser On You should be able to put SSILegacyExprParser Off in your .htaccess. I downloaded both of your files and (again, after changing the matched URLs) they appeared to work perfectly for me. - Y On Mon, Sep 15, 2014 at 11:23 AM, Simen Mangseth wrote: To take the good news first, I changed it to the echo element, and the encoding now works. Thanks. However, the expressions still refuses to work. I’m thinking maybe I already have the legacy filter on, because I read here that cPanel puts on that setting if you’re using EasyApache. I don’t know if I’m using EasyApache, but here’s the link anyways. Is there a way to check if the setting is on or off? If the legacy filter is on, are the new expressions still valid, too? I’ll just include the files anyways, if it’s my fault. It won’t work. I’m thinking, the old code worked if only one expression and not “||” (the or-sign), the new code doesn’t work on anything. the 404.shtml a small file defining some variables and including the error template 1HTTP.shtml. / Simen Fra: Yehuda Katz Sendt: søndag, 14. september 2014 19:54 Til: users@httpd.apache.org On Sun, Sep 14, 2014 at 4:03 AM, Simen Mangseth wrote: Thanks for your reply, Yehuda. However, I can’t get any of your suggestions to work. You can get the whole file if you want, but for the time being, I’ll just send the pieces of code that doesn’t work. Here’s the new if-code: I took this exact code and changed the URLs to match several that point to my server and it worked fine. What URLs are you expecting to hit? I can add them to my hosts file and see if they match. Now nothing works, not even the two last ones with no “||”-expression that worked before. I still use this to reference to this, though: DeDanseglade DDCountry Gullskoen Dans DansAS Should I change it to percentage, brackets and the tilde, too? I’ll try now. This is what I used: DeDanseglade DDCountry Gullskoen Dans DansAS I don’t want the legacy setting on, as I don’t like using old legacy stuff. If something changes, I should learn it and adapt to it rather than complaining and “wanting the old back” as so many does. However, I do think this new syntax is complicated… Your second suggestion (encoding=”none”) doesn’t have any effect. This is the full code, even though I don’t think it would be full of surprises: The output is “ etc..” made out of > and < html characters in the code. You need to set it on the I’ve read that there’s a new syntax, but on the website I don’t understand it, even after reading It many times. So the question is: How do I transform this simple expression into the new syntax? 2: When I’m creating a variable with #set like this: The HTML code appears in the output. I don’t get a paragraph, or bold text, as I want. How do I do this? This might be a bug, since the documentation says default encoding is none, but I was able to reproduce it. You can get around it by adding encoding="none" to your echo. For your example: I’m sorry, but I’v
Re: [users@httpd] Business Setup
Just a quick word of thanks to everyone who chimed in. John's decided to do a bit of boning up before taking the big plunge, so I guess I'm off the hook for now. :-) Bill - To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org For additional commands, e-mail: users-h...@httpd.apache.org
Re: [users@httpd] Business Setup
On Wed, Sep 17, 2014 at 11:05 AM, Bill Vance wrote: > > Just a quick word of thanks to everyone who chimed in. > John's decided to do a bit of boning up before taking > the big plunge, so I guess I'm off the hook for now. > Good to hear! FYI, I used to work in a company that wrote the interface between the point of sale -- card reader, website, whatever -- and the payment processor (which would then move money between accounts). It was expected that user would then create the interface -- website, cash register screen -- and make sure to keep the computer where the transactions were stored secured. And that worked fine with a lot of companies (and government institutions) big and small. Now, some companies would license our software and then create a website/interface thingie so companies with limited programming skills could use their system to handle the money part of the sales (for a fee of course). Paypal offers something similar to what I am talking about and so does squareup and probably google. That keeps you out of scope as Rainer was mentioning. My point is that is pays to contact those companies and check their prices. > :-) > > Bill > > > - > To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org > For additional commands, e-mail: users-h...@httpd.apache.org > - To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org For additional commands, e-mail: users-h...@httpd.apache.org
Re: [users@httpd] (36)File name too long
On 09/16/2014 02:50 PM, mmccar...@tribloom.com wrote: I am using RewriteRule and the proxy flag to proxy through Apache. When a long URL is passed through (longer than 255 characters), I get the error below (redacted). I understand that this is related to the maximum file name on the OS, in this case Ubuntu 14.04. My question is why is this happening when the URL is not related to a file on the file system? The URL is rewritten, then proxied to another server that works fine with long URLs. [Mon Sep 15 11:42:04.211290 2014] [core:error] [pid 18302:tid 140171735451392] (36)File name too long: [client xxx.xx.x.xxx:53717] AH00036: access to //_aliases failed (filesystem path '/), referer: http://xx.xx.xx.xxx/index.html Thanks, That error message doesn't appear to be from the httpd server itself (ie, that message doesn't appear anywhere in the source code for trunk, 2.4, 2.2, or 2.0), which leads me to believe that 1) it's in fact from your filesystem, and 2) there's no direct way to fix that in httpd configuration. As thy why it matters when the file isn't on the filesystem, that's hard to tell without more context, but I presume that at some point in the process it is *looking* for the file in the filesystem. For example, if this RewriteRule is in a .htaccess file, rather than in the main server config, it did in fact have to navigate to a filesystem directory before consulting that .htaccess file. -- Rich Bowen - rbo...@rcbowen.com - @rbowen http://apachecon.com/ - @apachecon - To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org For additional commands, e-mail: users-h...@httpd.apache.org
Re: [users@httpd] (36)File name too long
On Wed, Sep 17, 2014 at 12:52 PM, Rich Bowen wrote: > > On 09/16/2014 02:50 PM, mmccar...@tribloom.com wrote: > >> I am using RewriteRule and the proxy flag to proxy through Apache. When a >> long URL is passed through (longer than 255 characters), I get the error >> below (redacted). I understand that this is related to the maximum file >> name on the OS, in this case Ubuntu 14.04. My question is why is this >> happening when the URL is not related to a file on the file system? The URL >> is rewritten, then proxied to another server that works fine with long URLs. >> >> [Mon Sep 15 11:42:04.211290 2014] [core:error] [pid 18302:tid >> 140171735451392] (36)File name too long: [client xxx.xx.x.xxx:53717] >> AH00036: access to //_aliases failed (filesystem path >> '/), referer: http://xx.xx.xx.xxx/index.html >> >> Thanks, >> > > That error message doesn't appear to be from the httpd server itself (ie, > that message doesn't appear anywhere in the source code for trunk, 2.4, > 2.2, or 2.0), When you see "ANn", it is httpd >= 2.4, and you should just grep for the n part: ./server/request.c:ap_log_rerror(APLOG_MARK, APLOG_ERR, rv, r, APLOGNO(00036) ./server/request.c- "access to %s failed (filesystem path '%s')", ./server/request.c- r->uri, r->filename); > which leads me to believe that 1) it's in fact from your filesystem, and > 2) there's no direct way to fix that in httpd configuration. > > As thy why it matters when the file isn't on the filesystem, that's hard > to tell without more context, but I presume that at some point in the > process it is *looking* for the file in the filesystem. > > For example, if this RewriteRule is in a .htaccess file, rather than in > the main server config, it did in fact have to navigate to a filesystem > directory before consulting that .htaccess file. > > The decision to proxy via rewrite is being made too late in request processing for mod_proxy to prevent httpd looking for a file on disk to match the request, resulting in this issue. If there is a way to configure mod_proxy to handle the request (i.e., using mod_proxy directives), the filesystem check will be bypassed. -- Born in Roswell... married an alien... http://emptyhammock.com/
Re: [users@httpd] (36)File name too long
It's from ap_directory_walk()
else if ((rv != APR_SUCCESS && rv != APR_INCOMPLETE)
|| !(thisinfo.valid & APR_FINFO_TYPE)) {
/* If we hit ENOTDIR, we must have over-optimized, deny
* rather than assume not found.
*/
ap_log_rerror(APLOG_MARK, APLOG_ERR, rv, r, APLOGNO(00036)
"access to %s failed (filesystem path '%s')",
r->uri, r->filename);
return r->status = HTTP_FORBIDDEN;
}
On Sep 17, 2014, at 12:52 PM, Rich Bowen wrote:
>
> On 09/16/2014 02:50 PM, mmccar...@tribloom.com wrote:
>> I am using RewriteRule and the proxy flag to proxy through Apache. When a
>> long URL is passed through (longer than 255 characters), I get the error
>> below (redacted). I understand that this is related to the maximum file name
>> on the OS, in this case Ubuntu 14.04. My question is why is this happening
>> when the URL is not related to a file on the file system? The URL is
>> rewritten, then proxied to another server that works fine with long URLs.
>>
>> [Mon Sep 15 11:42:04.211290 2014] [core:error] [pid 18302:tid
>> 140171735451392] (36)File name too long: [client xxx.xx.x.xxx:53717]
>> AH00036: access to //_aliases failed (filesystem path
>> '/), referer: http://xx.xx.xx.xxx/index.html
>>
>> Thanks,
>
> That error message doesn't appear to be from the httpd server itself (ie,
> that message doesn't appear anywhere in the source code for trunk, 2.4, 2.2,
> or 2.0), which leads me to believe that 1) it's in fact from your filesystem,
> and 2) there's no direct way to fix that in httpd configuration.
>
> As thy why it matters when the file isn't on the filesystem, that's hard to
> tell without more context, but I presume that at some point in the process it
> is *looking* for the file in the filesystem.
>
> For example, if this RewriteRule is in a .htaccess file, rather than in the
> main server config, it did in fact have to navigate to a filesystem directory
> before consulting that .htaccess file.
>
> --
> Rich Bowen - rbo...@rcbowen.com - @rbowen
> http://apachecon.com/ - @apachecon
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
> For additional commands, e-mail: users-h...@httpd.apache.org
>
-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org
Re: [users@httpd] (36)File name too long
Thanks for the info. I think the problem is that I am trying to use the
REMOTE_USER in the rewrite for example:
RewriteCond %{LA-U:REMOTE_USER} !^$
Which is later used in the RewriteRule. I just checked and found that
when I remove the LA-U:REMOTE_USER part of the rewrite rule the error
does not occur. This bug report helped me to understand why it was
failing: https://issues.apache.org/bugzilla/show_bug.cgi?id=45187
I am not quite sure how I can fix my rules though. I understand that
using an LA-U causes a subrequest in order to get the authenticated user
and I believe this is what is causing the failure. (Auth causes a
directory walk?)
Any ideas on how to get the authenticated user for a RewriteRule without
causing a directory walk? I was tossing around the idea of using an env
var or a cookie, but both seem like bad ideas.
Thanks,
Michael
On 9/17/2014 11:04 AM, Jim Jagielski wrote:
It's from ap_directory_walk()
else if ((rv != APR_SUCCESS && rv != APR_INCOMPLETE)
|| !(thisinfo.valid & APR_FINFO_TYPE)) {
/* If we hit ENOTDIR, we must have over-optimized, deny
* rather than assume not found.
*/
ap_log_rerror(APLOG_MARK, APLOG_ERR, rv, r, APLOGNO(00036)
"access to %s failed (filesystem path '%s')",
r->uri, r->filename);
return r->status = HTTP_FORBIDDEN;
}
On Sep 17, 2014, at 12:52 PM, Rich Bowen wrote:
On 09/16/2014 02:50 PM, mmccar...@tribloom.com wrote:
I am using RewriteRule and the proxy flag to proxy through Apache. When a long
URL is passed through (longer than 255 characters), I get the error below
(redacted). I understand that this is related to the maximum file name on the
OS, in this case Ubuntu 14.04. My question is why is this happening when the
URL is not related to a file on the file system? The URL is rewritten, then
proxied to another server that works fine with long URLs.
[Mon Sep 15 11:42:04.211290 2014] [core:error] [pid 18302:tid 140171735451392] (36)File
name too long: [client xxx.xx.x.xxx:53717] AH00036: access to //_aliases failed (filesystem path '/), referer:
http://xx.xx.xx.xxx/index.html
Thanks,
That error message doesn't appear to be from the httpd server itself (ie, that
message doesn't appear anywhere in the source code for trunk, 2.4, 2.2, or
2.0), which leads me to believe that 1) it's in fact from your filesystem, and
2) there's no direct way to fix that in httpd configuration.
As thy why it matters when the file isn't on the filesystem, that's hard to
tell without more context, but I presume that at some point in the process it
is *looking* for the file in the filesystem.
For example, if this RewriteRule is in a .htaccess file, rather than in the
main server config, it did in fact have to navigate to a filesystem directory
before consulting that .htaccess file.
--
Rich Bowen - rbo...@rcbowen.com - @rbowen
http://apachecon.com/ - @apachecon
-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org
