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.
Related
I use apache 2.4.41 and I would like to deny direct access to image files on my server.
I've implemented the following code in my apache configuration file :
SetEnvIf Referer "(www\.)?mywebsite\.net" localreferer
<FilesMatch "\.(jpg|png|gif)$">
Require env localreferer
</FilesMatch>
However I have a strange behavior. In a web browser, when a try to access an image file directly with its url, I don't get a 403 error code (as expected) and the image is displayed. But, when reloading the page (F5 or cmd+R on a mac), the ressource is blocked and a 403 error status is displayed.
When trying a curl -I, I have the following result :
HTTP/1.1 302 Found
Date: Wed, 06 Jul 2022 14:31:35 GMT
Server: Apache/2.4.41 (Ubuntu)
Location: http://www.mywebsite.net/error/403.php
But I should get HTTP/1.1 403 Forbidden...
Could someone help me with this issue ?
Many thanks in advance.
https://api.aonesalons.com/dbsynch/webocitysalonpos/
When I send a request to the mentioned URL from POSTMAN, it works fine.
However, when sent through my angular application, running at demo.aonesalons.com,
I get:
Failed to load https://api.aonesalons.com/dbsynch/webocitysalonpos/: The 'Access-Control-Allow-Origin' header contains multiple values '*, https://demo.aonesalons.com', but only one is allowed. Origin 'https://demo.aonesalons.com' is therefore not allowed access.
If I directly hit https://api.aonesalons.com/dbsynch/webocitysalonpos/in browser, it works. However, when the same url is accessed from angular app running at demo.aonesalons.com, it throws multiple CORS header error
In angular app or on directly hitting it in browser, I see that response for this request is 200, with this response:
Access-Control-Allow-Credentials:true
Access-Control-Allow-Headers:*
Access-Control-Allow-Origin:*
Access-Control-Allow-Origin:https://demo.aonesalons.com
Access-Control-Expose-Headers:Cache-Control, Content-Type, Server
Cache-Control:must-revalidate, max-age=172800
Connection:close
Content-Length:240
Content-Type:application/json
Date:Sun, 25 Feb 2018 05:02:27 GMT
Expires:Tue, 27 Feb 2018 05:02:27 GMT
Server:CouchDB/1.6.1 (Erlang OTP/R14B04)
When I hit it through postman,
access-control-allow-headers →*
access-control-allow-origin →*
cache-control →must-revalidate, max-age=172800
connection →close
content-length →240
content-type →text/plain; charset=utf-8
date →Sun, 25 Feb 2018 05:11:50 GMT
expires →Tue, 27 Feb 2018 05:11:50 GMT
server →CouchDB/1.6.1 (Erlang OTP/R14B04)
All my requests are proxied through apache server which has
Access-Control-Allow-Origin:*
but
before coming up with *, I had
#SetEnvIf Origin ^(https?://(?:.+\.)?aonesalons\.com(?::\d{1,5})?)$ CORS_ALLOW_ORIGIN=$1
#Header append Access-Control-Allow-Origin %{CORS_ALLOW_ORIGIN}e env=CORS_ALLOW_ORIGIN
Now,
After having switched it to , all response headers have Access-Control-Allow-Origin: except for this request to couchdb . I am not sure where it is picking this from.
Here's what my ssl.conf looks like:
Header always set Access-Control-Allow-Headers "*"
Header always set Access-Control-Allow-Origin "*"
<VirtualHost *:443>
ServerName api.aonesalons.com
SSLEngine on
SSLCertificateFile /home/user/abc.crt
SSLCertificateKeyFile /home/user/bcf.key
ProxyPreserveHost On
ProxyRequests Off
ProxyPass /dbsynch http://0.0.0.0:5984/
ProxyPassReverse /dbsynch http://0.0.0.0:5984/
ProxyPass / http://localhost:9999/
ProxyPassReverse / http://localhost:9999/
</VirtualHost>
As stated in the error message:
The 'Access-Control-Allow-Origin' header contains multiple values '*, https://demo.aonesalons.com', but only one is allowed
Only one entry of Access-Control-Allow-Origin is allowed in a HTTP response. Now since you are using a ProxyPass, it is highly likely that the target application creates it's own header entry for Access-Control-Allow-Origin, which your Apache Server forwards - and in addition to that, it adds the entry containing *, since you specified this in your configuration.
So I guess that in your Angular app you have somewhere something like .header("Access-Control-Allow-Origin","(something)"); if you remove this, your app should be accessible via your Apache server.
Alternatively, you may remove the entry Header always set Access-Control-Allow-Origin "*" in your apache config and alter your Angular app in a way that it set the correct header.
you need to enable CORS on apache configure file.
Just add his line to inside your sites-enabled folder config file
Header set Access-Control-Allow-Origin "https://domain_name.com"
My backend Tomcat server sends a 302 redirection with a relative path.
HTTP/1.1 302
Date: Wed, 13 Dec 2017 16:55:05 GMT
Server: Apache TomEE
Location: /StoreWeb/catalog/cotton-shirts
Content-Length: 0
I have this reverse proxy setup in Apache.
ProxyPass /catalog/ http://localhost:8080/StoreWeb/catalog/
ProxyPassReverse /catalog/ http://localhost:8080/StoreWeb/catalog/
But this is not having any effect on the Location header. Apache leaves it unchanged. How can I have Apache convert:
Location: /StoreWeb/catalog/cotton-shirts
To:
Location: /catalog/cotton-shirts
Performing URL rewrites as part of a ProxyPass is a Bad Idea™. You should deploy your webapp in Tomcat under the same URL as you intend to mount it into your URL space and you will never have any of these problems.
If you do manage to re-write the URL in your Location header, I think you'll find that you then have to re-write all of the URLs in all of the pages dynamically-generated by the StoreWeb application. Once you fix those, you'll find that the cookies have the wrong path. And on. And on.
Just deploy your application on the same URL path and your life will be infinitely easier.
I had the same problem and solved it with the following configuration:
ProxyPass /path1 http://server2/path2
ProxyPassReverse /path1 http://server2/path2
ProxyPassReverse /path1 /path2
I'm not sure of that being a 'best practice', though
I am trying to configure Apache 2.4 with mod_proxy as a reverse proxy and I'm having a problem with redirects not passed from the origin server to the client.
I have the following configuration in the virtual host configuration:
[...]
ProxyPreserveHost On
# ProxyPass "/" "http://old.domain.tld/"
ProxyPassReverse "/" "http://old.domain.tld/"
[...]
When using the commented-out ProxyPass directive in the virtual host config, everything works fine. Which means a 30x-redirect from the origin server gets correctly rewritten and forwarded to the client.
When configuring the ProxyPass in .htaccess (which I need because this only should happen under certain conditions), the reverse proxy is working fine except that it does not process any redirects to the client.
I have the following .htaccess:
RewriteEngine On
RewriteRule ^(.*)$ http://old.domain.tld/$1 [P]
Now, I always get a 404 - not found in the client, when the origin server sends a 30x-Redirect.
In the proxy server log, I can see the following traces:
[...] strip per-dir prefix: /[...]/domain.tld/htdocs/ ->
[...] applying pattern '^(.*)$' to uri ''
[...] rewrite '' -> 'http://old.domain.tld/'
[...] escaped URI in per-dir context for proxy, http://old.domain.tld/ -> http://old.domain.tld/
[...] forcing proxy-throughput with http://old.domain.tld/
[...] go-ahead with proxy request proxy:http://old.domain.tld/ [OK]
The client gets the following headers delivered:
HTTP/1.1 404 Not Found
Date: Fri, 25 Nov 2016 14:04:23 GMT
Server: Apache/2
Content-Length: 1060
Content-Type: text/html; charset=utf-8
Keep-Alive: timeout=5, max=100
Proxy-Connection: Keep-alive
I don't understand why Apache or mod_rewrite/mod_proxy is not forwarding the correct redirect when configured in .htaccess.
Is there any solution for that? Or am I doing something wrong?
Thank you.
ProxyPassReverse its spected to handle redirects so origin server wont take the client outside of the proxy.
This directive lets Apache adjust the URL in the Location,
Content-Location and URI headers on HTTP redirect responses. This is
essential when Apache is used as a reverse proxy (or gateway) to avoid
bypassing the reverse proxy because of HTTP redirects on the backend
servers which stay behind the reverse proxy.
Only the HTTP response headers specifically mentioned above will be
rewritten. Apache will not rewrite other response headers, nor will it
rewrite URL references inside HTML pages. This means that if the
proxied content contains absolute URL references, they will bypass the
proxy. A third-party module that will look inside the HTML and rewrite
URL references is Nick Kew's mod_proxy_html.
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.