I am using swagger-UI 2.1.3 for API documentation and in backend, I am using spring-webmvc .
I have one API which returns a pdf file, it works fine if I type the URL in browser (it popups a download and downloaded file works fine)
But the same api won't works in swagger ui, it gives me a download link after clicking on "try out", and that link downloads a file, but that file shows me blank pdf pages (corrupted pdf file) .
The response headers are following
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: public
Expires: 0
Access-Control-Allow-Origin: *
Content-Description: File Transfer
Content-Transfer-Encoding: binary
Transfer-Encoding: chunked
Content-Disposition: attachment; filename="example.pdf"
Access-Control-Expose-Headers: Content-Description,Content-Disposition,location
Content-Type: application/pdf
Content-Length: 268288
Date: Mon, 04 Jan 2016 12:18:16 GMT
Any solution around this ?
Addition Info:
This questions seems similar -
AngularJS: Display blob (.pdf) in an angular app
There they are saying that set responseType to arraybuffer in xhr, But i think that swaggar will take care of that (maybe i need to set some configuration??)
Related
The send and receive content on the server I work on is with type "application/xml".
On my init section I added the below line to automatically to add to all my header requests
web_add_auto_header("Content-Type","application/xml");
When I run the script, I get response header showing the correct content-type but in the boo day I get message:
351-byte response headers for "http://172.29.67.68/svc/bw/cti/monitor/event/bw_perfuser1000_60a439f7-599d-4fe1-baa6-598391312954" (RelFrameId=1, Internal ID=5)
HTTP/1.1 200 OK\r\n
Date: Mon, 11 Mar 2019 18:20:09 GMT\r\n
Content-Length: 681\r\n
Content-Type: application/xml\r\n
X-Frame-Options: SAMEORIGIN\r\n
Expires: Thu, 01 Jan 1970 00:00:00 GMT\r\n
Cache-Control: no-cache, private, must-revalidate, max-stale=0, post-check=0, pre-check=0
no-store\r\n
Pragma: no-cache\r\n
Keep-Alive: timeout=15, max=96\r\n
Connection: Keep-Alive\r\n
message I get:
HTML parsing not performed for Content-Type "application/xml" ("ParseHtmlContentType" Run-Time Setting is "TEXT").
To fix this issue, I need to add the below line before each request
web_add_header("Content-Type","application/xml");
Can anyone please explain why I need to explicitly mention the content-type before each request although I used the web_add_auto_header() function?
In HTTP protocol, you need to specific Request Header Fields in HTTP request. The detail of HTTP Header please refer to wiki.
Context
My github pages are not refreshing. After diagnosing my conclusion is it's a server side caching effect.
What I did + diagnostic results
The site is working OK.
I made a change in index.html in my local
repo, then commit and push
I completely cleared my browser cache (btw also using cache clear plugins, and Chrome dev tools set not using cache)
Reloaded the page, with ctrl+f5 and ctrl+R (change is not applied)
Checked using github.com read index.html, the change is there, committed.
Monitored the traffic with Fiddler. The request for index.html sent, full response received, the content is the old NOT changed.
Examined the response header with Fiddler, says: (see header exhibit)
Reverse diagnostic
I've issued a request with a usual trick typeing: index.html?v001orAnythingYouWant and I got the new version of the page
Problem
Problem solved one can say, but it is not true. When I refresh images, css, js still this effect will prevent me to see the new result.
Question
How can I configure or overcome this server side caching, of course only for development/testing time?
Response header exhibit
HTTP/1.1 200 OK
Server: GitHub.com
Content-Type: text/html; charset=utf-8
Last-Modified: Fri, 06 May 2016 12:24:29 GMT
Access-Control-Allow-Origin: *
Expires: Fri, 06 May 2016 12:45:44 GMT
Cache-Control: max-age=600
X-GitHub-Request-Id: B91F111E:5AA6:47804:572C8F9F
Content-Length: 43752
Accept-Ranges: bytes
Date: Fri, 06 May 2016 12:35:57 GMT
Via: 1.1 varnish
Age: 13
Connection: keep-alive
X-Served-By: cache-fra1238-FRA
X-Cache: HIT
X-Cache-Hits: 1
Vary: Accept-Encoding
X-Fastly-Request-ID: 1758f53052edbfb40a0044407d53d5654ad1e983
ASP.NET MONO MVC4 application is running in apache with mod_mono
Pages should cached only in browser or in proxy servers to save server memory.
Browser gets product list from server using header
Request URL:http://example.com/store/Store/Category/ANDRORI?root=1&open=True&total=2.76
Request Method:GET
Status Code:200 OK
Remote Address:1.2.3.4:80
Server returns returns product list page with headers:
HTTP/1.1 200 OK
Date: Wed, 06 Jan 2016 16:52:47 GMT
Server: Apache/2.2.22 (Debian)
X-AspNet-Version: 4.0.30319
Cache-Control: private
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 8668
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=utf-8
Chrome Developer Tools page audit wrote warning about this page
The following resources are explicitly non-cacheable. Consider making them cacheable if possible:
and read this page every time. Response contains
Cache-Control: private
so page must me cached in browser.
How to fix this so that page can cached in client?
I tried to add controller
[OutputCache(Location = System.Web.UI.OutputCacheLocation.Client, Duration = 20 * 60)]
but in this case page is cached in server and query string parameters are ignored.
Same page is sent from server for all query string parameters.
I'm working on a delphi api for Google docs and having a hard time getting the upload to work. I'm following Google's development guide here and from what I understand it looks like the process should go like this:
Make a POST request to this url: https://docs.google.com/feeds/upload/create-session/default/private/full/?access_token=my_access_token&v=3&convert=false with these headers: X-Upload-Content-Type and X-Upload-Content-Length
Get a 200 OK response with the next upload location stored in the Location header
Make a PUT request to the Location header with the header Content-Type set to whatever I had X-Upload-Content-Type set to in step 1 and the header Content-Range set to something like this: bytes 0-524287/2097152 and the first 512kb of data in the body
Get a 308 Resume Incomplete Response that has the next upload location in the Location header
Go back to 3 until all bytes are uploaded, at which point I will receive a 201 Created response that will have the xml data describing the file I uploaded
Everything up to and including step 3 works fine. It is at step 4 that things start to go wrong.
The one thing that confuses me the most is that the response on step 4 doesn't contain a Location header. I figured that meant I should just send the next request to the same url, but that causes me to get a 504 error. I tried the entire process with fiddler just to see if it was the delphi code, a lack of understanding on my part, or something that google is doing.
Here's the requests and responses I sent and received using fiddler:
POST https://docs.google.com/feeds/upload/create-session/default/private/full/?access_token=my_access_token&v=3&convert=false HTTP/1.1
Content-Type: application/x-www-form-urlencoded
X-Upload-Content-Type: application/octet-stream
X-Upload-Content-Length: 2097152
Content-Length: 0
Host: docs.google.com
HTTP/1.1 200 OK
Server: HTTP Upload Server Built on May 16 2012 12:03:24 (1337195004)
Location: https://docs.google.com/feeds/upload/create-session/default/private/full/?access_token=my_access_token&v=3&convert=false&upload_id=AEnB2Ur9-9VxMSI6kaFzbybY2qiyzK6kVoKzcZ6Yo02H8Ni4FlQFl_N06DdjZXzp3vSjOPH3CEb_4vDlKZp7VlC0hxpkypzlKg
Date: Tue, 22 May 2012 16:53:27 GMT
Pragma: no-cache
Expires: Fri, 01 Jan 1990 00:00:00 GMT
Cache-Control: no-cache, no-store, must-revalidate
Content-Length: 0
Content-Type: text/html
PUT https://docs.google.com/feeds/upload/create-session/default/private/full/?access_token=my_access_token&v=3&convert=false&upload_id=AEnB2Ur9-9VxMSI6kaFzbybY2qiyzK6kVoKzcZ6Yo02H8Ni4FlQFl_N06DdjZXzp3vSjOPH3CEb_4vDlKZp7VlC0hxpkypzlKg HTTP/1.1
Content-Type: application/octet-stream
Content-Length: 524288
Content-Range: bytes 0-524287/2097152
Host: docs.google.com
[first 512kb of data here]
HTTP/1.1 308 Resume Incomplete
Server: HTTP Upload Server Built on May 16 2012 12:03:24 (1337195004)
Range: bytes=0-524287
X-Range-MD5: bd9d4ee7afa24b7da0e685f05b5f1f44
Date: Tue, 22 May 2012 16:54:29 GMT
Pragma: no-cache
Expires: Fri, 01 Jan 1990 00:00:00 GMT
Cache-Control: no-cache, no-store, must-revalidate
Content-Length: 0
Content-Type: text/html
PUT https://docs.google.com/feeds/upload/create-session/default/private/full/?access_token=my_access_token&v=3&convert=false&upload_id=AEnB2Ur9-9VxMSI6kaFzbybY2qiyzK6kVoKzcZ6Yo02H8Ni4FlQFl_N06DdjZXzp3vSjOPH3CEb_4vDlKZp7VlC0hxpkypzlKg HTTP/1.1
Content-Type: application/octet-stream
Content-Length: 524288
Content-Range: bytes 524288-1048575/2097152
Host: docs.google.com
[next 512kb of data]
HTTP/1.1 504 Fiddler - Send Failure
Content-Type: text/html; charset=UTF-8
Connection: close
Timestamp: 10:54:14.056
The only thing I was able to do was to be able to say for a fact that it is not just the delphi code that is wrong, and since I don't think it's google, I'm going to have to go with I don't understand something that should be happening. What am I missing?
Edit
I was able to get the upload working, I'm not entirely sure what I did differently, but the documentation is a little misleading. At least it is to me. When you send a PUT request, you don't get a new location, you just continue to upload to the same one. Also, when you finish the upload, the 201 response doesn't contain the actual XML data, instead, it has a Location header that points to where you can grab the XML data from. Not a huge deal but a little confusing.
It seems like the 504 error is returned by Fiddler, these two links should help:
https://urda.com/blog/2010/09/28/iis-services-504s-and-fiddler/
https://urda.com/blog/2010/09/30/follow-up-iis-services-504s-and-fiddler/
I have two very similar pieces of ASP.NET code that send a file in an HTTP Reponse to the client. They should cause the browser to prompt to save the file. The first one works, the second one doesn't. The HTTP responses as seen in Fiddler are below.
Working:
HTTP/1.1 200 OK
Cache-Control: private
Content-Length: 228108
Content-Type: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
X-AspNet-Version: 4.0.30319
content-disposition: attachment; filename=Report.xlsx
Date: Wed, 05 Jan 2011 12:17:48 GMT
<binary data>
Not working:
HTTP/1.1 200 OK
Server: ASP.NET Development Server/10.0.0.0
Date: Wed, 05 Jan 2011 12:19:21 GMT
X-AspNet-Version: 4.0.30319
Content-Length: 228080
content-disposition: attachment; filename=report 2.xlsx
Cache-Control: private
Content-Type: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet
Connection: Close
<binary data>
When the first one is seen in Fiddler the browser correctly prompts to save the file. When the second one is seen in Fiddler, nothing observable happens in the browser. Same behaviour in both chrome and firefox.
Any idea why this is happening?
EDIT: ASP.NET code that produces the second response
Response.Buffer = false;
Response.ContentType = #"application/vnd.openxmlformats-officedocument.spreadsheetml.sheet";
Response.AppendHeader("content-length", genstream.Length.ToString());
Response.AppendHeader("Content-Disposition", string.Format("attachment; filename={0}.xlsx", filename));
byte[] buffer = new byte[1024];
genstream.Position = 0;
int n;
while ((n = genstream.Read(buffer, 0, 1024) ) > 0)
{
Response.OutputStream.Write(buffer, 0, n);
}
The space in the filename parameter value might cause this. Try the quoted-string syntax instead:
Content-Disposition: attachment; filename="report\ 2.xlsx"
See also RFC 2183.
I'm actually a little surprised the first one is working - I thought browsers were pretty picky about case in HTTP headers.
Try changing the "content-disposition" header to "Content-Disposition".
Problem is here:
Connection: Close
A lot of browsers - especially for downloads - use 100-and-continue to read the headers and check the length of the content. The second will not allow the browser to do that.
(UPDATE)
This is generated because of this line:
Response.Buffer = false;
Remove it and it should work as a charm!
Apparently it wasn't a problem with the response but a problem with the request. Both the HTTP responses in the OP are valid, but the link on the page that produced the second one was inside an asp ajax panel (UpdatePanel). I've been staring at this problem for too long and know too little about HTTP protocol to look into the exact cause of it but the differences in the request headers were these fields:
Working (outside ajax panel):
Cache-Control: max-age=0
Content-Type: application/x-www-form-urlencoded
Accept: application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Not working (inside ajax panel):
X-Requested-With: XMLHttpRequest
X-MicrosoftAjax: Delta=true
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Cache-Control: no-cache
Accept: */*
Problem is now gone after removing the link from the ajax panel. "Connection: Close" is still in the (now working) header so that was obviously nothing to do with the problem.
Thanks for the help!