I want to encode a long Base64 encoded string within the URL.
Currently long URLs (over 300 chars) that are rewritten under mod-rewrite result in a forbidden(402) error.
If my request URL is 355 characters it results in error, however when I reduce it to 300 it works.
Is there a default value in the server that limits the request line size?
I couldn't find the LimitRequestLine/FieldSize directive anywhere in my server configuration.
Here is my rewrite rule:
RewriteEngine On
RewriteCond %{DOCUMENT_ROOT}%{REQUEST_FILENAME} !-f
RewriteCond %{DOCUMENT_ROOT}%{REQUEST_FILENAME} !-d
RewriteRule ^json/ base64json.php [L]
A URL looks something like this:
http://sub.mydomain.com/json/longrandomnumbers?param=xxx
I wish to extract randomnumbers and param from the rewritten url, but it says forbidden permission denied, inside apache2 error log, it says:
Mon Mar 19 21:03:31.711559 2018] [core:error] [pid 20504] (36)File name too long: [client 167.220.24.128:45071] AH00036: access to /json/eyJldmVudHMiOlt7InNlc3Npb25JZCI6InMxNTAxMjY0OTIzeDYyZjg4MTNlNjkzMWM5eDU4MjQ0MjY2IiwiaW5zdGFudGlhdGlvbiI6IjkxMTMwMDQ3MTQ3OTE1ODgiLCJpbmRleCI6MCwiY2xpZW50VGltZXN0YW1wIjoxNTIwMzg3NTkwLjE2OSwibmFtZSI6ImNyZWF0aXZlTG9hZGVkIiwidmlld2FiaWxpdHkwME1lYXN1cmFibGUiOnRydWUsInZpZXdhYmlsaXR5NTAxTWVhc3VyYWJsZSI6ZmFsc2V9XX0= failed (filesystem path '/var/www/track/json/eyJldmVudHMiOlt7InNlc3Npb25JZCI6InMxNTAxMjY0OTIzeDYyZjg4MTNlNjkzMWM5eDU4MjQ0MjY2IiwiaW5zdGFudGlhdGlvbiI6IjkxMTMwMDQ3MTQ3OTE1ODgiLCJpbmRleCI6MCwiY2xpZW50VGltZXN0YW1wIjoxNTIwMzg3NTkwLjE2OSwibmFtZSI6ImNyZWF0aXZlTG9hZGVkIiwidmlld2FiaWxpdHkwME1lYXN1cmFibGUiOnRydWUsInZpZXdhYmlsaXR5NTAxTWVhc3VyYWJsZSI6ZmFsc2V9XX0=')
and
failed (filesystem path
'/var/www/track/json/eyJldmVudHMiOlt7InNlc3Npb25JZCI6InMxNTAxMjY0OTIzeDYyZjg4MTNlNjkzMWM5eDU4MjQ0MjY2IiwiaW5zdGFudGlhdGlvbiI6IjkxMTMwMDQ3MTQ3OTE1ODgiLCJpbmRleCI6MCwiY2xpZW50VGltZXN0YW1wIjoxNTIwMzg3NTkwLjE2OSwibmFtZSI6ImNyZWF0aXZlTG9hZGVkIiwidmlld2FiaWxpdHkwME1lYXN1cmFibGUiOnRydWUsInZpZXdhYmlsaXR5NTAxTWVhc3VyYWJsZSI6ZmFsc2V9XX0=')
I tried to add RequestLine/FieldSize to apache2.conf, no use, wondering how to by pass the limit for the file system I use and why it's so annoying to check the length somehow before redirect to the correct path which is base64json.php, could I do it as a long parameter instead? It might be caused by ubuntu files system.
I am using Apache2.4.7 on Ubuntu 14.02.
This must be defined before loading any Virtual Host.
Add this in yours apache2.conf, right.
Did you restarted apache daemon after edit?
sudo service apache2 restart
Related
My current project needs some cleaner urls. I got it until the ID part like http://test.com/profile/1337(additional backslash)
I want to hide the "ugly" stuff like http://test.com/profile.php?plid=1337&action=view that would appear. Users shouldn't see this.
Already tried to add some "hardcoded" params like
RewriteRule ^profile/([0-9\_]+)/history/?$ ./profile.php?plid=$1&action=history [NC,QSA]
Also tried to change [NC,QSA] to [L,QSA], [QSA,L], [NC,QSA,L] and so on.
These are my rewrite rules currently not working
RewriteRule ^profile/([0-9\_]+)/edit/?$ ./profile.php?plid=$1&action=edit [NC,QSA]
RewriteRule ^profile/([0-9\_]+)/history/?$ ./profile.php?plid=$1&action=history [NC,QSA]
And this rule is working fine
RewriteRule ^profile/([0-9\_]+)/?$ ./profile.php?plid=$1&action=view [NC,QSA]
I want to display some buttons like "history, edit" if the action is "view" (which works fine at the moment)
Expecting a working url like https://test.com/profile/1337/history
(Where $action should be 'history')
My error is currently a 404 page not found.
[Sat Sep 07 11:36:20.981057 2019] [:error] [pid 20923] [client ip:port] script '/var/www/main/hk/profile.php' not found or unable to stat
Here is a slightly modified version of your rule set. I remove the case insensivity (why should that matter?) and also the QSA flag since it is standard anyway. Using the END flag instead of L with save you a lot of hassle, if your http server supports it , more on that further down.
RewriteEngine on
RewriteRule ^/?profile/([0-9\_]+)/?$ /profile.php?plid=$1&action=view [END]
RewriteRule ^/?profile/([0-9\_]+)/view/?$ /profile.php?plid=$1&action=view [END]
RewriteRule ^/?profile/([0-9\_]+)/edit/?$ /profile.php?plid=$1&action=edit [END]
RewriteRule ^/?profile/([0-9\_]+)/history/?$ /profile.php?plid=$1&action=history [END]
Make sure you are not looking at earlier results cached on the client side. So disable your browser cache for that site or use a fresh anonymous tab for testing.
In case you receive an internal server error (http status 500) using the rule above then chances are that you operate a very old version of the apache http server. You will see a definite hint to an unsupported [END] flag in your http servers error log file in that case. You can either try to upgrade or use the older [L] flag, it probably will work the same in this situation, though that depends a bit on your setup.
This implementation will work likewise in the http servers host configuration or inside a dynamic configuration file (".htaccess" file). Obviously the rewriting module needs to be loaded inside the http server and enabled in the http host. In case you use a dynamic configuration file you need to take care that it's interpretation is enabled at all in the host configuration and that it is located in the host's DOCUMENT_ROOT folder.
And a general remark: you should always prefer to place such rules in the http servers host configuration instead of using dynamic configuration files (".htaccess"). Those dynamic configuration files add complexity, are often a cause of unexpected behavior, hard to debug and they really slow down the http server. They are only provided as a last option for situations where you do not have access to the real http servers host configuration (read: really cheap service providers) or for applications insisting on writing their own rules (which is an obvious security nightmare).
In the mod_rewrite documentation for Apache 2.2, the RewriteRule [R] flag states:
Any valid HTTP response status code may be specified, using the syntax [R=305], with a 302 status code being used by default if none is specified. The status code specified need not necessarily be a redirect (3xx) status code. However, if a status code is outside the redirect range (300-399) then the substitution string is dropped entirely, and rewriting is stopped as if the L were used.
In addition to response status codes, you may also specify redirect status using their symbolic names: temp (default), permanent, or seeother.
However the following snippet of code only seems to allow the "symbolic names":
# Force HTTPS
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteCond %{HTTPS} off
# this works
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=permanent,NE]
# this doesn't work
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=308,NE]
The error log shows:
[Tue May 23 23:11:12 2017] [alert] [client 192.168.33.1] /var/www/html/ventus/.htaccess: RewriteRule: invalid HTTP response code '308' for flag 'R'
However, 308 appears to be the HTTP status code for permanent redirect: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/308
Is this a bug in Apache or am I doing something wrong?
You can't use 308 with your version of apache (2.2). The support for 308 status was added in apache 2.4.3: https://archive.apache.org/dist/httpd/CHANGES_2.4.3
core: Add missing HTTP status codes registered with IANA.
Yes, this is a bug. Your interpretation of the documentation is correct, and all codes in the range 300-399 should be accepted.
I have had some difficulties with my site after updating my servers to use PHP version 5.4.. I have been through a lot of support tickets and browsed the internet for 2 days.. Now I need to ask directly to the people who actually know about it.
After updating the php version I started to get a 500 error on my pages and it turned out that my rewrite rules in my htaccess file wasn't working anylonger. They did in php version 5.2 but not in 5.4.
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
# If the request is for a valid directory
RewriteCond %{REQUEST_FILENAME} -d [OR]
# If the request is for a valid file
RewriteCond %{REQUEST_FILENAME} -f [OR]
# If the request is for a valid link
RewriteCond %{REQUEST_FILENAME} -l
RewriteRule ^ - [L]
# external redirect from actual URL to pretty one
RewriteCond %{THE_REQUEST} \s/+website\.php\?id=([^\s&]+) [NC]
RewriteRule ^ %1? [R=302,L]
RewriteRule ^([\w.-]+)/?$ website.php?id=$1 [L,QSA]
RewriteRule ^([\w.-]+)/([\w.-]+)/?$ website.php?id=$1&page=$2 [L,QSA]
</IfModule>
Can anybody tell me what I have to do differently? I would really appreciate it.
EDIT:
I got this copy from my livechat with hostgator:
[Thu Jun 26 03:54:07 2014] [error] [client ] malformed header from script. Bad header=<br />: website.php
[Thu Jun 26 03:55:35 2014] [error] [client ] Cannot load the ionCube PHP Loader - it was built with configuration 2.2.0, whereas running engine is API220100525,NTS
[Thu Jun 26 03:55:35 2014] [error] [client ] The Zend Engine API version 220100525 which is installed, is newer.
[Thu Jun 26 03:55:35 2014] [error] [client ] Contact Zend Technologies at http://www.zend.com/ for a later version of Zend Optimizer.
[Thu Jun 26 03:55:35 2014] [error] [client ]
Try adding this line:
zend_extension = /usr/local/ioncube/ioncube_loader_lin_5.4.so
to your php.ini
SOLUTION IS NOW FOUND
I made the wrong assumption to think it was due to my rewrite rule. The problem seemed to be at HostGator. If you host at HostGator, this will be helpful for you. The reason all this started was because HostGator has announced, that the will upgrade the servers to run PHP 5.4 as standard instead of PHP 5.2. What they didn't mention, was the structure of their servers and how individual sites has to manage their individual PHP files.
Well I found out that by changing the name of my php.ini file in the root directory (making it invalid for the server to use), the system located a PHP version specific php.ini file in the main servers directory. This made me realize that the php.ini file in my root directory had to be changed completely, so therefor I created a new php.ini file containing the 5.4 version. The site didn't change, because the files were basically identical, but it made it possible for me to use the EZConfig in cPanel again.
This is what to do:
Change PHP version either in the PHP configuration tab in cPanel, or
by adding AddHandler application/x-httpd-php54 .php to your
.htaccess file.
Open File Manager in cPanel.
Locate your root folder (Home) and find the php.ini file.
If you want to keep your existing php.ini file as a backup, rename it to ex. php_old.ini.
Create a new file named php.ini and insert the content from following link: https://wiki.cac.washington.edu/display/webpub/php.ini+for+PHP+5.4
Good luck with it. Hope this will solve it for somebody as well, so that they don't have to spend 3 days solving it themselves.
I'm attempting to use htaccess to write my urls as localhost/username instead of localhost/profile.php?id=username
I looked it up and this is what I found to be the solution
DirectoryIndex index.php
RewriteEngine On
RewriteRule ^(.*)$ /profile.php?id=$1 [L]
That's an exact copy from this stackoverflow question htaccess rewrite for query string however, for some reason it always returns a 500 error. I'm not sure why it's giving me this since I'm no expert with htaccess. I pretty much just find code modify it to fit my use.
Mod_rewrite is definitely turned on. So I know that can't be the issue. Any idea what is wrong with the code I have?
Edit:
This is what the apache error log returned.
[Sat Apr 27 14:20:10.558122 2013] [core:error] [pid 3244:tid 1688] [client 127.0.0.1:58653] AH00124: Request exceeded the limit of 10 internal redirects due to probable configuration error. Use 'LimitInternalRecursion' to increase the limit if necessary. Use 'LogLevel debug' to get a backtrace.
If it's really a redirect loop per your comment, try adding this line immediately before your rule:
RewriteCond %{REQUEST_URI} !-f
The part where it says /profile.php?id=$1 is where it will rewrite you to. If that;s not a file then it would show up with an error so change that to whatever file you want it to rewrite you to.
Hope this helped
Kevin
I have the following .htaccess on an Apache/2.4.2-win32 server:
# Turn mod_rewrite on
RewriteEngine On
# Allow direct loading of files in the static directory
RewriteCond %{REQUEST_FILENAME} -f
RewriteRule ^/?static/(.+)$ - [L]
# Send all other requests to controller
RewriteCond ${REQUEST_URI} !^/?(spf/index\.php)?$
RewriteRule .* spf/index.php [L,QSA]
This works well and does exactly what I want it to. For those of you who can't be bothered working out what it does, it sends all requests through spf/index.php unless they are for a file that exists in the static directory.
The file resides in the virtual host's documentroot.
Every request that falls through this .htaccess generates the following error:
[Wed Aug 01 14:14:16.549835 2012] [core:warn] [pid 7100:tid 1076] AH00111: Config variable ${REQUEST_URI} is not defined
This is not actually causing a problem - every request works as expected - but it's filling up my error log and I don't like it.
According to Google, no-one has ever had this error before. That's as far as I've got with debugging it, I don't really know where to go next.
Anyone got any idea what's going on here?
P.S. I'm aware this might be a question better suited to SF, if the general opinion is that it doesn't belong here I'll move it.
You need to replace the $ with a %:
RewriteCond ${REQUEST_URI} !^/?(spf/index\.php)?$
to
RewriteCond %{REQUEST_URI} !^/?(spf/index\.php)?$