I have an issue where my Apache server is returning an Upgrade H2 header response sporadically. This causes the following issue with Safari and HTTP2:
http2 error: Invalid HTTP header field was received: frame type: 1, stream: 1, name: [upgrade], value: [h2]
HTTP/2 stream 0 was not closed cleanly: PROTOCOL_ERROR (err 1)
I have seen similar issues on stackoverflow but none of the proposed solutions have worked for me. I have tried setting "Header unset Upgrade" in the httpd.conf file as well as the ssl.conf and virtualhost specific configuration files. I also tried to unset the header in a location directive in those files.
I have removed the h2c protocol from the mod_http2.c configuration in httpd.conf based on other people having this problem but it did not work by itself or in conjunction with the other changes above.
Protocols h2 http/1.1
I have no idea why the Header unset Upgrade statement is not working. We are using Apache as a reverse proxy with a tomcat application backend. We also have an AWS ALB in front of Apache. Does anyone know why this would not be working or another way to remove the response header "Upgrade"?
Related
I am setting Cache-Control in the httpd.conf where i also have Mellon SSO Configuration. I am getting two cache-control included in the response headers. So i have commented out the MellonEnable "info" and restarted the apache. Now my Cache-Control got reflected and now it is only mine. But this is not an exact solution to turn off/override the cache-control, so i find out that there is an option that controls whether the Cache-control header is sent back in responses in Mellon configuration.
So i have given MellonSendCacheControlHeader Off in the conf file, but the apache is throwing issue like "Invalid command 'MellonSendCacheControlHeader', perhaps misspelled or defined by a module not included in the server configuration"
Can someone help ?
Forgot to Update the Answer.
Actually the latest Mellon version 0.13.0 have the fix. Here there is a fix to "Allow disabling the Cache-Control HTTP response header". So the duplicate Cache-Control will be avoided, if we set the MellonSendCacheControlHeader Off in the conf file.
Un-install the older version of Mellon and install the version 0.13.0 and update the conf file with the configuration MellonSendCacheControlHeader Off. Restart the Apache Server once all changes done. It will work.
I am running a Wicket web application in Apache Tomcat on two separate servers. When the application runs on server #1, all of the images are delivered without errors or warnings on both http: and https:, so I don't think there is a problem with the html file. When I run the same application on server #2, all of the images are delivered over http:, but some of the images are giving 404 Not Found when delivered over https:.
For example:
/path/image1.png and is delivered successfully over http and https.
/path/some/sub/directory/image2.png is delivered over http, but not delivered over https.
More specifically, if I request https://domain/path/some/sub/directory/image2.png, I get a 404 error. But if I specify the port and request https://domain:8443/path/some/sub/directory/image2.png the image is delivered.
As the images both work on the first server, I suspect there is some problem with my Apache configuration on the second server. I can't find any directives specific to the functioning or malfunctioning directories in the apache2.conf, httpd.conf, or .htaccess files.
Where should I look to find the directive that allows image1 to be delivered successfully so that I can copy the rules for image 2?
:::EDIT:::
I found the following directives in extras/httpd-ssl.conf. We are using varnish to cache static content.
# Terminate SSL here and pass everything to Varnish
RequestHeader set X-Forwarded-Proto "https"
ProxyPreserveHost on
ProxyPass / http://128.138.128.89:80/
ProxyPassReverse / http://128.138.128.89:80/
This is running on Linux Mint on Oracle VirtualBox if that matters.
We're running Sonatype's Nexus to store all of our builds, cache our dependencies, etc. etc. However, I'd like to move away from the default install's port 8081 URL and instead host it over SSL via an Apache proxy. I've setup Apache's mod_proxy to proxy to it such that https://myserver.com/nexus brings up Nexus. I used the following configuration directives inside of my virtual host config:
# Configure mod_proxy to be used for proxying URLs on this site to other URLs/ports on this server.
ProxyRequests Off
ProxyVia Off
ProxyPreserveHost On
<Proxy *>
AddDefaultCharset off
Order deny,allow
Allow from all
</Proxy>
# Proxy the Sonatype Nexus OSS web application running at http://localhost:8081/nexus
<Location /nexus>
ProxyPass http://localhost:8081/nexus
ProxyPassReverse http://localhost:8081/nexus
</Location>
This seems to match the instructions at Running Nexus Behind a Proxy. However, I was unable to clear the "Base URL" setting in Nexus: it wouldn't let me leave it blank.
And everything mostly works: I can access Nexus at the HTTPS URL, log in, and perform most GUI functions.
However, when logging in I get the following warning message:
WARNING: Base URL setting of http://myserver.com/nexus does not match your actual URL! If you're running Apache mod_proxy, here's more information on configuring Nexus with it.
And not everything in the GUI actually works. So far I've noticed the following:
System Feeds: Gives the following error:
Problem accessing /nexus/service/local/feeds. Reason:
The resource identified by the request is only capable of generating response entities which have content characteristics not acceptable according to the accept headers sent in the request
Nexus returned an error: ERROR 406: The resource identified by the request is only capable of generating response entities which have content characteristics not acceptable according to the accept headers sent in the request
Deleting Hosted Repositories: I went through and deleted several empty & unneeded repositories. However, after confirming the deletions, only the first was removed. I had to login to the 8081 site to delete any of the others.
Per the documentation, it looks like a better solution may be to add a RequestHeader to the Apache configuration:
RequestHeader set X-Forwarded-Proto "https"
I tried the accepted answer, which appears to work, but once I added the RequestHeader, I was able to uncheck Force URL and the warning was cleared. I have not tested the other behavior the OP is describing, though.
You just need to adjust the baseUrl setting in the Administration->Server configuration screen. Set the url you are using and click the Force Base Url option.
I'm using NSurlconnect and an NSurlrequest to get the http headers from a static txt file served from an apache server but it does not return the last modified date.
What Apache server configuration directive would prevent this or what could i have the server guys add to the configuration to enable this to show.
FYI I have tried other urls on different servers and i am able to get last-modified from them.
This turned out to be a problem with certificates and the solution was to revise the allowable canAuthentiateAgainstProtectionSpace options.
It caused me some confusion because I received a response and it allowed me to download the file even though the response was a http 401 response. once I fixed the authenificiation problem i started to get the correct 304 and 200 options back from the server along with all the expected headers
I hate to answer my own question but I think that the reason the header is not stowing last=modified is that there are .htaccess files somewhere in the configuration of the server that specify
Header unset last-Modified
or that some other mod or apache2.cnf has some other directive..
if anyone knows better please advise.
so far I developed completey locally, having everything (Apache, Openfire, JSJaC application) on my laptop, running quite fine. Now I want to use remote server for Apache/Openfire. I did basically the same steps, incl. the whole http-bind stuff. I test the setting with simpleclient.html provided by JSJaC.
Now here's the deal, if I use the simpleclient directly on the remote server - e.g., http://here.domain.org/simpleclient.html - it works. If I use it locally - e.g., http://[local_machine]/simpleclient.html - and with the same settings I get an 503 (service unavailable). It seems to be more a network/Apache issue than Openfire/JSJaC one, but I'm not an expert.
My parameters for the simpleclient:
HTTP Base: http://here.domain.org/http-bind/
JabberServer: here.domain.org
So in my apache virtual host conf file I have the lines:
AddDefaultCharset UTF-8
ProxyReqests On
ProxyPass /http-bind/ http://127.0.0.1:7070/http-bind/
So basically the http bind works since I can connect when the simpleclient.html resides on the server. What I tried so far:
checked if 7070 open from extern: yes
checked etc/hosts - here the relevant lines
127.0.0.1 localhost
123.123.123.123 here.domain.org here
checked Apache conf for restrictions: can't find any, basically i have an "Allow from all" everywhere (but I'm not completely sure where to look at)
By the way, with,e.g., Pidgin I can connect from my laptop to the remote server. Just the JSJaC simpleclient won't do. So I assume it's the http-bind that causes the trouble. I would understand if port 7070 weren't open, but it is.
Any hints or help are much appreciated!
Christian
Ok, I got it. It was a cross-domain scripting issue. I started looking into the JSJaC library and noticed that it makes XmlHttpRequests which by default won't work across different domains. I therefore had to allow this with Apache on the Openfire-Server. I added the follwing entries in the VirtualHost conf file:
Header always set Access-Control-Allow-Origin "*"
Header always set Access-Control-Methods "POST, GET, OPTIIONS"
Header always set Access-Control-Allow-Credentials true
Header always set Access-Control-Allow-Headers "Content-Type, *"
Of course the mod_headers module must be loaded for this.
I'm not sure which entries are actually required, I didn't try every combinations. I think the always is needed since the request to the http-bind address is a proxy thingy.