I am building a web application, and I have to handle international characters (with stuff like "J'ai surveillé des élève à la rôtule"). Some of the data is in arbitrary static text file that are in an arbitrary directory on the file system. Those files are all utf-8 (thanks standardization!)
To serve this data, I am using an embedded jetty, with the ResourceHandler handler. I don't have any web.xml file. In addition to the static, I have a bunch of restful API that get handled trough servlet.
Problem is, Jetty ResourceHandler class doesn't seem to send a charset along with the static file Content-Type . If I request index.html, Content-Type is text/html. To correctly handle accentuated character, I would like for it to be Content-Type: text/html; charset=utf-8
For file that have a default charset of utf-8 like text/html or text/css, this is fine, but some text file dont have one and get wrongly interpreted as Windows-1252 and the accented character get garbled (I just got a Québec Liquor Store back, instead of Québec Liquor Store). Is there a way to specify a default character set and tell jetty to always send it? Something like apache AddDefaultCharset utf-8
Hardcoding everything to UTF-8 is wrong.
How about just specifying the extension to mime-type mapping for those files you want to control?
MimeTypes mimeTypes = resourceHandler.getMimeTypes();
mimeTypes.addMimeMapping("txt", "text/plain; charset=UTF-8");
Related
When using Google PageSpeed tester, I get the following:
The following resources have no character set specified in their HTTP headers. Specifying a character set in HTTP headers can speed up browser rendering.
http://www.ntainc.com/
I have searched everywhere, and can't seem to figure out why it isn't "reading" my charset. I have it listed in the html document header:
<meta charset="utf-8">
And in my web.config file:
<?xml version="1.0" encoding="UTF-8"?>
and there is an .htaccess file:
AddDefaultCharset utf-8
I believe our server is an IIS. What am I missing?
The warning is referring to the HTTP Content-Type header. It is being sent by your webserver to the client like this:
Content-Type: text/html
It needs to be sent like this instead:
Content-Type: text/html; charset=utf-8
You need to check your webserver configuration. Your .htaccess addition should be adding the charset attribute to the header, but apparently is not. So either you put it in the wrong .htaccess file, or the server is ignoring it.
The fact that your HTML contains a <meta charset> tag is irrelevant to the warning, as the HTML is just arbitrary data inside of the HTTP response body (though it does allow an HTML5-enabled client to process your UTF-8 encoded HTML correctly).
Your web.config charset is irrelevant, as it is only interpreted by your webserver, not a client.
I'm stuck with this problem for two days now. The jersey verion is 2.6.
I have enabled the logging of the request by adding a loggingfilter. Which works well.
My rerquest is logged using the right charset:
Content-Disposition: form-data; name="verskomm"
kleine Änderung
Wenn I want to consume this request using #FormDataParam I get
kleine ?nderung
Where can I set the charset which should be used to decode these parts of the request?
I have no influence on the request, as it is made by a third party program.
I am using valums file-uploader to upload files. This works great if my Spring controller returns void. If I add a #Responsebody Object to my controller IE things that I am about to download instead of uploading a file and launches a dialog.
The reason I would like to have a #Responsebody Object and not void is for error handling. How can I trick IE in this case?
I'm assuming that Spring is automagically setting the content-type to application/json for you, which will not work in IE. Ensure the content-type of your response is text/plain. Some will say that text/html is correct, and that is true for most cases. However, text/html will cause you problems if your JSON response contains HTML as IE will mess with the response. So, your safest bet is to ensure the content-type of your response is text/plain.
While we are on the topic of IE quirkiness, also be sure that you only return a 200 response if you intend to also include JSON in your response. IE will, by default, replace the content of "small" non-200 responses with a "friendly" message. "Small", I believe, is defined as a response that is less than 512 (or possibly 256) bytes.
For a list of all things you should be aware of when using IE, have a peek at the "limitations of IE" section in the Fine Uploader readme.
I was trying to find a way to prevent browsers from caching PDF that is being loaded using a streaming methods.
FireFox and Chorme deals just fine with the following headers and doesn't cache any pdf file:
Response.AddHeader("Pragma", "no-cache, no-store");
Response.AddHeader("Cache-Control", "no-cache, no-store, must-revalidate, max-age=0");
Response.AddHeader("Expires", "-1");
Although, IE 7 (with acrobat reader 9.4.1) works only with the following headers and prevent the caching of the PDF doc:
Response.AddHeader("Pragma", "no-cache, no-store");
Response.AddHeader("Cache-Control", "private, must-revalidate, max-age=0");
Response.AddHeader("Expires", "-1");
When i was trying to use IE 7 with Acrobat Reader 10, the above header didn't make any different and cached the PDF no matter what i tried.
When i am trying to put Cache-Control: no-cache, no-store, the pdf was not loaded at all.
According to my understanding, IE use the cache mechanism to load the PDF documents.
Is there anyone familiar with a global or specific way (by using other headers for example) that can help prevent caching of PDF documents?
Add a random number to the URL, either in the path or in the query string. That way, it'll download the file every time. You could also change the number only, if the file has changed, for example using the mtime of the file.
PHP (since everybody understands that, even if nobody likes it):
Download PDF
This issue of showing PDF (and other document types) inline with the use of the no-cache header has been filed as a bug to Microsoft: http://support.microsoft.com/kb/316431. IE uses its own caching mechanism when reading PDFs inline.
Unfortunately, the folks at M$ said this "works as designed" and users should not use the no-cache header... go figure.
You could try VSU's idea of using a Java PDF reader... I may go this route too.
Controlling the cache settings down the pipe is not fool proof. The alternative is to encode the realtime and date in the file name of the PDF.
You can encode the time date into the filename of the PDF so that each time a request is made the filename is unique.
Response.AddHeader "Content-Disposition","attachment;filename=somename" + CurrentDate() + Currenttime() ".pdf"
CurrentDate adn CurrentTime are imaginary functions. You need to write that code.
One of the request parameters in an http request made by the client contains Japanese characters. If I make this request in Firefox and look at the parameter as soon as it reaches the server by debugging in Eclipse, the characters look fine. If I do the same request using IE 8, the characters get garbled when I look at them at the same point in the server code (they are fine in both browsers, though). I have examined the POST requests made by both browsers, and they both pass the same sequence of characters, which is:
%2C%E3%81%9D%E3%81%AE%E4%BB%96
I am therefore thinking that this has to do with the encoding. If I look at the HTTP headers of the request, I notice the following differences. In IE:
Content-Type: application/x-www-form-urlencoded
Accept: */*
In Firefox:
Content-Type application/x-www-form-urlencoded; charset=UTF-8
Accept-Charset ISO-8859-1,utf-8;q=0.7,*;q=0.7
I'm thinking that the IE 8 header doesn't state the UTF-8 encoding explicitly, even though it's specified in the meta tag of the HTML document. I am not sure if this is the problem. I would appreciate any help, and please do let me know if you need more information.
Make sure the page that contains the form has UTF-8 as charset. In IE's case, the best thing to make sure of this is by sending a HTTP header ('Content-Type: text/html; charset=utf-8') and adding a meta http-equiv tag with the content type/charset to your html (I've seen this actually matter, even when the appropriate header was sent).
Second, your form can also specify the content type:
<form enctype="application/x-www-form-urlencoded; charset=utf-8>