Need help on below rewrite rule. It's keep redirecting rather proxy
RewriteRule ^/corenet/life(/?|.html)$ /contentsite/sites12/corenet/life.html [P,L]
GET /corenet/life.html HTTP/1.1
User-Agent: curl/7.15.5 (x86_64-redhat-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5
Host: www-stage.sitesx.com
Accept: /
< HTTP/1.1 302 Found
< Date: Thu, 24 Aug 2017 13:55:51 GMT
< Server: Apache
< Location: https://www-stage.sitex.com/contentsite/sites12/corenet/life.html
< Content-Length: 0
Issue is fixed. Actually this is a node behind f5 loadbalancer with HTTPS Redirect. www-stage.sitex.com IP's is Load Balanced IP ( F5 VIP). When Node does reverse proxy to www-stage.sitex.com/contentsite/sites12/corenet/life.html request reaches to F5 LB that send 302 for https. To fix i have updated /etc/hosts of node F5's-VIP-IP www-stage-sitex.com. After it works !
Related
I used htaccess to limited ip which can connect to admin and user login page.
RewriteCond %{REMOTE_ADDR} !=127.0.0.1
RewriteRule (admin|user)$ http://redirect_example.com [R=301,L]
But the problem here is I used 301 redirect which mean when I can't change url http://redirect_example.com to another url. It's has already cached. My curl -I http://example.com/user result:
HTTP/1.1 301 Moved Permanently
Date: Fri, 17 Feb 2017 03:46:19 GMT
X-Content-Type-Options: nosniff
Cache-Control: max-age=1209600
Expires: Fri, 03 Mar 2017 03:46:19 GMT
Content-Length: 313
Content-Type: text/html; charset=iso-8859-1
Location: http://redirect_example.com
Age: 251965
X-Cache: HIT
X-Cache-Hits: 56
Connection: keep-alive
How do I change http://redirect_example.com to another url?
Caused by Varnish. You should ban the cache by run the command:
varnishadm
Then ban the cache by domain:
ban req.http.host ~ "redirect_example.com"
It's just cached in your browser. Clear your browser cache. You can use 302 redirects while testing to help with this.
I own a domain name (let's call it example.org), and have set up a CNAME pointing from foo.example.org to an AWS ELB FooBar-Load-Balancer-123456789.us-east-1.elb.amazonaws.com. That ELB has a Port Configuration of 443 (HTTPS, ACM Certificate <GUID>) forwarding to 80 (HTTP). The sole EC2 instance behind the ELB runs a Docker image exposing Apache on port 80.
When I open https://foo.example.org in my web browser, everything works fine - the page loads as expected. If I navigate to https://foo.example.org/path, it likewise loads correctly. However, if a page contains <a href="path">, upon clicking that the browser attempts to load http://foo.example.org/path, which (correctly) gives an error - "ERR_CONNECTION_REFUSED" in Chrome, "Unable to connect" in Firefox.
Checking the network activity in Chome Dev Tools, I see an initial request to https://foo.example.org/path which results in 301 Moved Permanently (from cache) with Location http://foo.example.org/path. This is obviously what's causing the browser's behaviour - is this misconfiguration on my server (which believes itself to be serving on HTTP - or, at least, port 80), on my ELB, or on the site's html itself?
I guess I could get around this by using absolute paths, but, given that I want to be able to spin up a Docker image locally (opening <IP Address>/path in my browser) to test before pushing changes, that doesn't sound like a true solution.
EDIT: Inspired by this, I checked behaviour in a fresh Chrome Incognito Mode window and in Chrome after clearing history - same behaviour in all cases.
Posting this as an answer since I'm technically unblocked, although I'd still very much appreciate someone more knowledgable explaining why these symptoms occurred.
A bit of investigation with curl led me to this:
$ curl -v https://foo.example.org/path
* Trying 52.0.230.252...
* Connected to foo.example.org (52.0.230.252) port 443 (#0)
* TLS 1.2 connection using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
* Server certificate: example.org
* Server certificate: Amazon
* Server certificate: Amazon Root CA 1
* Server certificate: Starfield Services Root Certificate Authority - G2
> GET /path HTTP/1.1
> Host: foo.example.org
> User-Agent: curl/7.43.0
> Accept: */*
>
< HTTP/1.1 301 Moved Permanently
< Content-Type: text/html; charset=iso-8859-1
< Date: Sun, 05 Jun 2016 18:35:58 GMT
< Location: http://foo.example.org/path/
< Server: Apache/2.4.7 (Ubuntu)
< Content-Length: 336
< Connection: keep-alive
<
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>301 Moved Permanently</title>
</head><body>
<h1>Moved Permanently</h1>
<p>The document has moved here.</p>
<hr>
<address>Apache/2.4.7 (Ubuntu) Server at foo.example.org Port 80</address>
</body></html>
* Connection #0 to host foo.example.org left intact
$ curl https://foo.example.org/path/ # Note trailing slash
<expected html>
So it looks like making a request to apache for a directory without a trailing slash ("Directories require a trailing slash, so mod_dir issues a redirect to http://servername/foo/dirname/."). That explains why the Location header in the 301 response used http:// - apache was serving http://, so "knew no better". I guess I can solve this by making my anchor tags explicitly link to a href with a trailing slash.
Why is Apache configured this way? Why not just automatically resolve to the appropriate location "internally", without having to make a round-trip of the 301 response? And, most importantly - is there a better way for me to solve this problem? Can ELB's be configured to rewrite Location headers (I guess not - I'm not InfoSec pro, but that strikes me as a vulnerability waiting to happen)? Can Apache?
I have setup apache2 with django and mod_wsgi in Debian Wheezy. I enabled mod_mem_cache with this configuration:
<IfModule mod_mem_cache.c>
CacheEnable mem /
MCacheSize 400000
MCacheMaxObjectCount 100
MCacheMinObjectSize 1
MCacheMaxObjectSize 500000
CacheIgnoreNoLastMod On
CacheIgnoreHeaders Set-Cookie
</IfModule>
based on the fact that MCacheMaxStreamingBuffer is the smaller of 100000 or MCacheMaxObjectSize as stated in the docs.
When I try hitting a page with size 3.3KB I get these response headers in firebug:
Connection Keep-Alive
Content-Encoding gzip
Content-Type text/html; charset=utf-8
Date Wed, 27 Aug 2014 14:47:39 GMT
Keep-Alive timeout=5, max=100
Server Apache/2.2.22 (Debian)
Transfer-Encoding chunked
Vary Cookie,Accept-Encoding
and the page isn't served from cache. In the page source there is however the correct header 'Cache-Control: max-age=300,must-revalidate' but doesn't show up in firebug.
In apache log I only see correctly:
[info] mem_cache: Cached url: https://83.212.**.**/?
With another test page that I created outside of django that doesn't have chunked encoding as a header, caching works fine. Why is the page not served from cache? Has anyone seen something similar?
I'am doing a web based application and what I did is to disable some of the HTTP methods are not necessary for the website specifically: OPTIONS, HEAD and TRACE.
I put this on the httpd.conf of my xampp to test if this works:
RewriteEngine On
RewriteCond %{REQUEST_METHOD} !^(GET|POST|PUT)
RewriteRule .* - [R=405,L]
Now my problem is how would i know if it is really deactivated or this particular setting is working properly? Are there tools that could facilitate this. I'm just new to server side administration.
Please someone help me.
You could just use telnet/netcat to verify this. Assuming that you're not using HTTPS, something like below should work perfectly to test:
$ telnet www.google.com 80
Trying 74.125.239.49...
Connected to www.google.com.
Escape character is '^]'.
OPTIONS / HTTP/1.1
Host:
HTTP/1.1 405 Method Not Allowed
Content-Type: text/html; charset=UTF-8
Content-Length: 962
Date: Tue, 17 Dec 2013 20:18:22 GMT
Server: GFE/2.0
Alternate-Protocol: 80:quic
Rinse and repeat for any other method that you have disabled, and that will tell you for sure whether the configuration works or not.
We're using Apache in front of Jenkins. Jenkins' Ajax calls include a n header that apparently needs to survive the roundtrip. If we access Jenkins on port 8080, then the n header is included in the response, if we access it through mod_proxy, the n header is getting stripped.
I tried using mod_headers to preserve this header, but for some reason that doesn't work. Is there any other way I can force mod_proxy to leave this header alone?
Edit 1:
This is the response getting returned by Jenkins.
HTTP/1.1 200 OK
Server: Winstone Servlet Engine v0.9.10
Content-Type: text/html;charset=UTF-8
n: 131
Connection: Close
Date: Tue, 20 Mar 2012 09:53:42 GMT
X-Powered-By: Servlet/2.5 (Winstone/0.9.10)
This is what Apache is returning:
Connection:close
Content-Encoding:gzip
Content-Type:text/html;charset=UTF-8
Date:Tue, 20 Mar 2012 10:37:21 GMT
Transfer-Encoding:chunked
Vary:Accept-Encoding
Edit 2:
It turns out Nginx does pass the appropriate headers back. That's the way I managed to solve it now. Still the original question is relevant: is there any way to get it done using Apache?
I found a way to get around this issue under apache.
it was created by alex (see https://issues.jenkins-ci.org/browse/JENKINS-327)
basically
my jenkins running at "http://localhost:8080/jenkins"
I want to access it via jenkins.mydomain.com.
now when I access jenkins.mydomain.com apache will redirect me to jenkins.mydomain.com/jenkins, not perfact but at least works.
<VirtualHost *:80>
ServerName jenkins.mydomain.com
Redirect / http://jenkins.mydomain.com/jenkins
<Location /jenkins>
ProxyPass http://localhost:8080/jenkins
ProxyPassReverse http://localhost:8080/jenkins
</Location>
</VirtualHost>
I eventually moved to Nginx. Nginx didn't strip out the headers. Still, it remains weird that you cannot get Apache to leave the n header alone.