When a request is coming in, it goes through apache sever before going to application server written in tomcat. In most cases, I can set the response header from apache server to return a certain response header like x-frame-options. However, depending on the page and requester, I would like to remove this x-frame-options in the apache layer.
So far, I tried following two options, but both did not work.
apache always set the header to generic, but application server override it to something else based on the condition.
apache Httpd.conf: Header always append X-Frame-Options SAMEORIGIN
Java Code: response.setHeader("X-FRAME-OPTIONS", "DENY");
application server set to something else then apache to check the header before setting to generic.
Java Code: response.setHeader("X-FRAME-OPTIONS", "DENY");
apache httpd.conf: RequestHeader set X-Frame-Options "SAMEORIGIN" env=no_my_header
I don't know what to do at this point. If anyone has any idea, I would appreciate.
Thanks,
Related
I have exposed few response headers through mule unfortnately the clinet (browser ) unable to see or missing the resposne headers at client side. I really dont know what exactly i have to configure in mule for expose the custom header responses to browser.
I see in internet like this header can help me to fix the issue but im not sure and also i dont know how to define this header in mule side.
access-control-expose-headers
I have a requirement in my application where a header other than default one sent in http request should be suppressed. Right now in my application when i send a request i am able to attach custom header fields.
Is there a way in apache tomcat configuration settings which will suppress headers other than default ones ? , i tried checking few sites, i found how to remove headers in response
http://www.shanison.com/2012/07/05/unset-apache-response-header-protect-your-server-information/
Is there any similar solution to remove request headers?
Thanks in adv.
i am working on java with Netbeans IDE and glassfish 3.1.2 i have created in rest services using jaxrs. when request from client is made ,i need to send json data in compressed format.to do this i have enabled the compression in glassfish as shown the following picture
but response got from the server is not compressed using gzip. it is receiving as normal json data. what should i do to overcome this issue
This is a solution for GF 3.1.2.2.
Responses to HTTP requests in version 1.0 are not compressed. You must send your requests in HTTP 1.1 to get gzipped responses from your glassfish server.
More over, you must add the header "Accept-Encoding: gzip" in your http requests.
To get a compressed response you need to have both sides agree to use it. You have configured GlassFish to send compressed responses. I can see that from the picture.
You need to make sure that your request to the services tells GlassFish that it can accept a compressed response. You normally do this by adding the following header to your HTTP requests: Accept-Encoding. You can read about the header in the RFC document that defines HTTP 1.1 request headers.
You can also get a lot of info from reading though SO questions about Accept-Encoding.
Is this done at the code level, perhaps through JAX-WS handlers? Or is it done through some configuration at the app server?
I've read something about web compression in general, it appears that just as the message is about to head to the wire, compression is applied. Clients should be able to accept a GZIP MIME type for them to be able to decompress the message.
I'd like to find out who's supposed to apply that compression and how it's done.
It can be done either by code or by configuring the server to do it on the fly. How it's done with server configuration varies widely depending on the server. For Apache, the tool to use is mod_deflate. The instructions when using JBoss are here.
To do it in code, you need to:
compress the data with gzip
set the content-length header to the length in bytes of the compressed response
include the following header in the response:
Content-encoding: gzip
The request should include the header:
Accept-encoding: gzip
More info can be found in Wikipedia.
We are using IBM Websphere Application Server 6.1 and browser is Internet Explorer 8.
We have a java servlet which dynamically generates PDF and MS Word documents. On the first attempt some users are saying they are getting
"Internet Explorer was unable to open this site. The requested site is either unavailable or cannot be found. Please try again later."
As per Microsoft Support article id 323308
When you try to open a Microsoft Office document or a PDF document over HTTPS (SSL) IE fails with above error message.
This issue occurs if the server sends a "Cache-control:no-store" header or sends a "Cache-control:no-cache" header.
For IE8 Microsoft suggests to add registry entry on users Windows XP desktop. This is not very practical for us to do as we don't control our users desktops. This does not happen for IE9, Firefox, Chrome, etc.
As per PK20531 WAS 6.1 is adding Cache-Control: no-cache="set-cookie, set-cookie2" and Expires
HTTP headers when there is cookie being set in the response.
Note - We are not setting the cookie in the servlet. The cookie is set by single sign-on software.
On the first attempt when the single sign-on (LTPA) cookie is being set and WAS is adding HTTP headers which IE browser does not like.
Does Java servlet api provide a way to remove http headers? Is there a technique to use Filter api to remove http headers?
If you remove the Cache-Control header from the response, then you're not sending any instructions about caching and therefore the caching behavior would be unpredictable.
It would be better to set the header to something else, rather than remove it. Presumably you want to enable caching on the browser for your pages. So you could add these lines to your servlet to enable caching in the browser:
response.setHeader("Pragma", "cache");
response.setHeader("Cache-Control", "private, must-revalidate");
You could do this in a Filter too, because filters have access to the HTTP response object. But if you've written your own servlet then it's probably more efficient — and clearer — to do it in the servlet.
It's all controllable by you. If you don't put it there, there will be nothing to remove.