I am trying to download following comics:
http://comicsbook.ru/upload/Комикс-Amazing-Super-Powers-Минутка-наркомании-81619.jpg
Sorry for url, but it is just image. You can easily look it in browser, even download via browser, but if I wget this url, I get html page, not image. What do I do wrong? I also tried perl download module. Same result.
if the referer is not set in the request, the server is redirecting(301) to a web page
I was able to get the jpg image by referer in header to: http://comicsbook.ru/funny/81619?minutka-narkomanii
wget --referer="http://comicsbook.ru/funny/81619?minutka-narkomanii" http://comicsbook.ru/upload/Комикс-Amazing-Super-Powers-Минутка-наркомании-81619.jpg
It means the default content-type is text/html.
You have to set the content type you want through the setContentType() method of your corresponding library. Here is an example in java
HttpGet request = new HttpGet(URL);
request.addHeader("accept", "image/jpeg");
Related
I want to get all css urls in QNetworkAccessManager in order to load the css url from database.
The easy solution to get the request's MIME type is by url path extensions, unfortunately this is not always the case.
how can I get the link resouce's type(css or img etc) or link resource's attribute like img/link/rel/type? seems like there is no interface to get CachedResource..
After uploading a PDF to the Media Archive, I am trying to link to it from a page on a site.
While editing content, I use the hyperlink tool then select the PDF I want to link to via the URL input box.
After saving and publishing the content, clicking the link downloads the PDF and I don't see any apparent way to make this view-able in the browser by using the current Media ID Composite provides. When rendered, we get this:
pdf
Is there a way that I can reference a PDF without using the Media ID and simply use the file name instead?
Here is the Request/Response header info:
After reading what Pauli Østerø said, I understand the problem but am still not able to think of a solution.
I can get the PDF to view in the browser by adding ?download=false to the href URL via Developer Tools. But when I try to add ?download=false to the href through Composite, it doesn't take affect and I get the console output: "Resource interpreted as Document but transferred with MIME type application/pdf: "http://c1.wittenauers.com/media/4afb7bc8-f703-469d-a9b2-a524d8f93dcb/ryc7iw/CompositeDocumentation.PDF"."
Here is the network trace that was asked for by Pauli. In the image, I included the bit where I add ?download=false to the URL, in source view, just in case there could be another way to add it.
Edit: URL and headers for the page.
Here is the link to the page that contains the link:
http://c1.wittenauers.com/cafe/test
Here is the headers for the page containing the link:
From what you're experiencing, it seems to me that Composite have gotten the MIME type of your uploaded file wrong, and is therefor not correctly telling the browser that this file is a pdf, and the browser doesn't know what to do with it.
Try deleting the file and uploading it again.
Try add ?download=false and the end of the href to the file. You prob. need to go into source mode of the content editor.
This is the exact line in the Source Code which is responsible for this behavior, and the logic is as follows
If there is no Querystring named download, the attachment is determined by the Mime Type. Only png, gif and jpeg will be shown inline, the rest will be shown as attachment.
If there is a Querystring named download with a value of false, it will override the Mime Type check and always force the Content-Disposition to be inline.
I made a quick test here to show that the behaviour is a expected. At least in my Chrome browser in Windows 8
Force download: https://www.dokument24.dk/media/9fdd29da-dde8-41f7-ba4c-1117059fdf06/z8srMQ/test/Prisblad%202015%20inkl%20moms.pdf
Show in browser: https://www.dokument24.dk/media/9fdd29da-dde8-41f7-ba4c-1117059fdf06/z8srMQ/test/Prisblad%202015%20inkl%20moms.pdf?download=false
Expanding on Pauli's answer, you can add the following snippet to your page template to automatically add the '?download=false' to all pdf links.
$("a").each(function () {
if (this.href.includes(".pdf")) {
this.href = this.href + "?download=false";
}
})
I'm creating some performance tests for a web application that sends requests of the same type that a browser would send to our server. One of these requests is a POST that uploads an image. I looked at this question where it looks like the actual contents of the image file should be inside the body of the request. However when I use F12 dev tools in Chrome to inspect what the browser sends in the request it looks like this:
------WebKitFormBoundaryjHN86sGb89n2HUZOT
Content-Disposition: form-data; name="profileImg[]"; filename="bmp.bmp"
Content-Type: image/bmp
------WebKitFormBoundaryjHN86sGb89n2HUZOT--
The space where I expected to see the file contents is blank. I was expecting to see some string of seemingly random characters representing the contents of the image file. There's also no path to the image in the request, only the name of the file, so I can't understand exactly how the file could be uploaded? Is Chrome just hiding the data from me?
Chrome hides the file data, when viewing the request payload using dev tools, for performance reasons:
https://groups.google.com/forum/#!topic/google-chrome-developer-tools/FaInquBDhU0
So I downloaded Fiddler and it actually shows that there is data being sent where we in Chrome see only a blank space. This means that Chrome does indeed hide the data.
I'm attempting to dynamically set the backgroundImage for a div where the image source url is not the true/final destination url but instead returns a 301 redirect pointing to the actual image url. Using this redirecting url in a standard < img src=" ... tag works normally as the browser transparently follows the redirect. However, it apparently does not do the same for backgroundImage.
My only thought at the moment is to use XMLHttpRequest to perform a HEAD request, determine the actual URL from the headers returned and use that as the backgroundImage, but this obviously involves significant overhead. Can anyone offer a better alternative?
Have a script build the image dynamically based on session or cookie data. I do it all the time.
Have your current script that is returning the 301 download/generate the image itself, or use URL rewriting to do the redirect at the server side.
If it's a small background image you might consider encoding it in BASE64.
body {
background-image:url(data:image/png;base64,<base64 STRING>");
}
I'm trying to write a Greasemonkey script that will convert all "Play" links on a page to embedded audio (using the <embed> tag).
When I use a link that I get from a GMail attachment, it works like a charm.
When I use a link from another site (Digium Switchvox), the HTTP response header has ContentType set to "application/octet-stream" instead of "audio/x-wav" (like GMail's link). This confuses Firefox, which decides that I don't have the right plugin installed. If I set the type attribute in the <embed> tag to "audio/x-wav", Firefox uses Quicktime to load the file. Quicktime gets confused, however, and won't play the file.
Does anyone know of a clever way to solve this problem?
have you tried overrideMimeType?
overrideMimeType
String (Compatibility: 0.6.8+) Optional.
A MIME type to specify with the request (E.G. "text/html; charset=ISO-8859-1").