My Java servlet includes the following line:
response.addHeader("Content-Disposition", "filename=myFile.pdf");
I need to include a named destination defined in the PDF file as part of the file name. Ideally, I could use the following:
response.addHeader("Content-Disposition", "filename=myFile.pdf#Chapter3");
but when I run it, the url in the browser shows /path/to/myFile.pdf%23Chapter3 instead of the desired /path/to/myFile.pdf#Chapter3.
How to escape the # in "filename=myFile#Chapter3"? Escaping with \ gives a compile-time error. Escaping with &035; doesn't work either.
RFC 2616 defines that "the Content-Disposition response-header field has been proposed as a means for the origin server to suggest a default filename if the user requests that the content is saved to a file" so I don't think you can do what you intend to through your servlet. Maybe you will have better luck with some script in the pdf : you could imagine parsing its own name to dynamically set it at the right anchor at opening.
Related
I'm showing a dropdown on a web page but when using characters as ○ as options, the dropdown shows a question mark
I'm getting the dropdown option from a SQL Server database in which the column that saves the value is nvarchar type
Then I create an XML output string with the values to send it as response of an AJAX call
When I do xmlWriter.toString() , being xmlWriter a StringWriter object, I'm able to see the ○ character using Eclipse's debug mode but that string needs to be sent as a ByteArrayOutputStream object to add it to response stream for the response to see the XML file on the client side but when doing xmlWriter.toString().getBytes() the ○ character becomes a question mark
I've tried to use xmlWriter.toString().getBytes("UTF-8") but the result is some strange symbols
What am I missing?
By guessing what might be your problem it feels like you're not specifying the encoding in your response object to the browser and it fails guessing the right one. Consider calling getBytes("UTF-8") as you did (better: getBytes(StandardCharsets.UTF_8)) and submit an encoding information along with your response, either in the HTTP header (Content-Type: application/xml; charset=utf-8) as you're probably using HTTP or in the XML header (<?xml version="1.0" encoding="utf-8"?>). Maybe even both as this will provide you the best compatibility.
In my file download API case an error like this.
org.apache.catalina.connector.ClientAbortException: java.io.IOException: Broken pipe
at org.apache.catalina.connector.OutputBuffer.realWriteBytes(OutputBuffer.java:380)
at org.apache.tomcat.util.buf.ByteChunk.flushBuffer(ByteChunk.java:420)
at org.apache.tomcat.util.buf.ByteChunk.append(ByteChunk.java:345)
at org.apache.catalina.connector.OutputBuffer.writeBytes(OutputBuffer.java:405)
at org.apache.catalina.connector.OutputBuffer.write(OutputBuffer.java:393)
at org.apache.catalina.connector.CoyoteOutputStream.write(CoyoteOutputStream.java:96)
at org.springframework.util.StreamUtils.copy(StreamUtils.java:128)
at org.springframework.util.FileCopyUtils.copy(FileCopyUtils.java:109)
at
I notice that the error only occurs when trying to download a file with a name containing comma(,) otherwise it works perfectly.
In my API I set the response like this:
response.setContentType("application/octet-stream");
response.setHeader(Constants.CONTENT_DISPOSITION, "attachment; filename= " + fileSeedName);
System.out.println(file.exists());
FileCopyUtils.copy(new BufferedInputStream(new FileInputStream(file)), response.getOutputStream());
response.flushBuffer();
Can anyone please help me.
Wrap the filepath in "Double Quotes"
the filename need double quotes to work
header('Content-Disposition:attachment;filename="' . $fileName . '.pdf"');
This is a known issue specific to Google Chrome specifically related to the Content-Disposition header. According to numerous references (just Google “Chrome content-disposition comma”), this is caused by the fact that chrome doesn't properly handle escaping of commas while Firefox, IE, etc. do. According to a few sites, this was introduced relatively recently and Google doesn't plan on fixing it.
Reference link
In http request, I have set the variable names are
username=$(name)
password=$(psw)
In CSV data set config set the details are:
File name: /home/desktop/login.txt
Variable name: name,psw
Delimiter use: ,
In CSV file, I have three user accounts are:
radha,radha
sumithra,sumithra
moorthi,moorthi
In the above configuration, I have run the jmeter3.0 in Linux . But, It does not read the CSV/txt file data. the below invalid request passing my application.
POST data:
username=%24%28name%29&password=%24%28psw%29&userstate=others&submit=Enter
Kindly give me a useful solution.
Every step you have followed seems okay here. But as I can see you have missed declaring the variable properly in your scripts. In your Http request sampler, you have to send parameter as like below:
username=${name}
password=${psw}
In Http sampler:
Since URLs often contain characters outside the ASCII set, the URL has to be converted into a valid ASCII format.
URL encoding replaces unsafe ASCII characters with a "%" followed by two hexadecimal digits.
So in your case, POST data is shown as "username=%24%28name%29" because of the ( and ).
For Reference, See HTML URL Encoding Reference.
I have a file named "MyFile.doc" on my server and a jsp in the same instance. There is a redirection in the jsp like : response.sendRedirect("MyFile.doc");. When a user comes to my jsp file, I want to give the file as "MyFile_XYZT.doc". In short, it should be downloaded with an ID created dynamically.
I've searched and found something about Content-Disposition method.
Any ideas ?
I've searched and found something about Content-Disposition method.
Right, that's how you tell the browser what you'd like it to do with the response, including optionally giving a suggested filename for a download.
I don't think there's any one-liner here, though. You either need to configure your server to return MyFile.doc with the relevant Content-Disposition header or, if you want to control the name with code in your JSP, you'll have to send the response yourself using setHeader to set the Content-Disposition header. E.g.:
response.setHeader("Content-Disposition", "attachment; filename=\"MyFile_XYZT.doc\"");
...and then opening the file, reading its contents, and sending those in the response. It's not a lot of code (probably four or five lines), but it's not a one-liner.
I have a servlet which receive some parameter from the client ,then do some job.
And the parameter from the client is Chinese,so I often got some invalid characters in the servet.
For exmaple:
If I enter
http://localhost:8080/Servlet?q=中文&type=test
Then in the servlet,the parameter of 'type' is correct(test),however the parameter of 'q' is not correctly encoding,they become invalid characters that can not parsed.
However if I enter the adderss bar again,the url will changed to :
http://localhost:8080/Servlet?q=%D6%D0%CE%C4&type=test
Now my servlet will get the right parameter of 'q'.
What is the problem?
UPDATE
BTW,it words well when I send the form with post.
WHen I send them in the ajax,for example:
url="http://..q='中文',
xmlhttp.open("POST",url,true);
Then the server side also get the invalid characters.
It seems that just when the Chinese character are encoded like %xx,the server side can get the right result.
That's to say http://.../q=中文 does not work,
http://.../q=%D6%D0%CE%C4 work.
But why "http://www.google.com.hk/search?hl=zh-CN&newwindow=1&safe=strict&q=%E4%B8%AD%E6%96%87&btnG=Google+%E6%90%9C%E7%B4%A2&aq=f&aqi=&aql=&oq=&gs_rfai=" work？
Ensure that the encoding of the page with the form itself is also UTF-8 and ensure that the browser is instructed to read the page as UTF-8. Assuming that it's JSP, just put this in very top of the page to achieve that:
<%# page pageEncoding="UTF-8" %>
Then, to process GET query string as UTF-8, ensure that the servletcontainer in question is configured to do so. It's unclear which one you're using, so here's a Tomcat example: set the URIEncoding attribute of the <Connector> element in /conf/server.xml to UTF-8.
<Connector URIEncoding="UTF-8">
For the case that you'd like to use POST, then you need to ensure that the HttpServletRequest is instructed to parse the POST request body using UTF-8.
request.setCharacterEncoding("UTF-8");
Call this before you access the first parameter. A Filter is the best place for this.
See also:
Unicode - How to get the characters right?
Using non-ASCII characters as GET parameters (i.e. in URLs) is generally problematic. RFC 3986 recommends using UTF-8 and then percent encoding, but that's AFAIK not an official standard. And what you are using in the case where it works isn't UTF-8!
It would probably be safest to switch to POST requests.
I believe that the problem is on sending side. As I understood from your description if you are writing the URL in browser you get "correctly" encoded request. This job is done by browser: it knows to convert unicode characters to sequence of codes like %xx.
So, try to check how do you send the request. It should be encoded on sending.
Other possibility is to use POST method instead of GET.
Do read this article on URL encoding format "www.blooberry.com/indexdot/html/topics/urlencoding.htm".
If you want, you could convert characters to hex or Base64 and put them in the parameters of the URL.
I think it's better to put them in the body (Post) then the URL (Get).