http://www.thomasnet.com/articles/hardware/fastener-threads
this image when viewing the requests with firebug in the net panel shows image/2 any idea why this would be set this way on the server side?
It's the only image being read from the 'articles/image/' folder (The rest come from the /images/images/' folder)
It's also the only image on the page which has a content-type at all.
And it's also the only image not cached.
My guess is that your web server is set to send certain header values based on directory.
Related
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 have written simple rewrite rules that rewrite .cfm extension links (using outbound rules), and resolve to the full .cfm path with an equivalent inbound rule. Example:
This outbound link:
http://mysite/section/page
Resolves to this full path:
http://mysite/section/page.cfm
When I visit a link without the file extension, in any browser, the page displays on the screen but the browser still seems to 'wait' for the page to finish loading (get that spinning circle in the browser tab, while Firefox says "transferring data from mywebsite...")
After about 5 minutes of 'waiting' for the page to load, the browser will stop trying to load and displays 'cannot display the page' error. I used Firebug's NET panel to see whats going on and basically the page never finishes loading (the size of the file remains 0kb until the browser falls over).
If I go to a fully qualified path page e.g. http://mysite/section/page.cfm then the page loads completely within about 20ms and Firebug gives me the size of the page.
Can anyone please suggest whats going on and how to fix it?
OK I have somewhat solved it, or actually solved it.
Its a ColdFusion issue. If anyone else if facing this here is what you do:
Create an Application.cfc page.
Add this function to your component:
<cffunction name="onRequestEnd">
<cfheader name="Content-Length" value="#Len(getPageContext().getOut().getString())#" />
<cfset getPageContext().flush()>
</cffunction>
So what is happening here is that we are setting the Content-Length header to a correct size because ColdFusion messes it up if you let it do it itself. The cure to ending the never-ending page load is to put the getPageContext().flush() after setting the Content-Length so that the browser gets all the page content.
Frankly I made it work with some Google searching and random hacking. It may not be the correct way to address the problem (because in Firebug it says there is a 500 error going on) but it seems to work.
I've created a project with the moovweb sdk and have trouble editing the content within an iframe on one of the pages. For instance, moving a div around inside the iframe doesn't seem to work with the tritium I'm writing. What can I do with tritium to make this work? The domains are different FYI.
Unfortunately, Tritium only allows you to edit the attributes of the iframe itself, not the content within.
This is because the request for content in the iframe is made after the browser constructs the DOM of the main page. Tritium can only intercept the first request for the main page, not the second request for content from a different domain.
I know of two workarounds:
Add the second website as a Moovweb project and you will be able to use Tritium to manipulate the content. Then you can point the iframe of the original page to this new content.
Use JavaScript/AJAX to modify the iframe's content.
However there are implications for production domains... I'm afraid I may have rushed this answer and will update it after I do more research.
If the iframe is on the same origin (http://m.yoursite.com) or on an origin you have in your config.json you can absolutely use tritium! However, maybe not in the way you expect!
So, the iFrame is going to make a separate request to the src attribute's location. If you ensure this request is going through the SDK (by rewriting it) like so:
$(".//iframe[#src]") {
attribute("src") {
rewrite("link")
}
}
Then you can map that url and perform your regular tritium on it!
you need to analyses the src of iframe and need to write mapping in mappings.ts for the url in src. Include proper .ts file in pages folder and start transforming it.
I am supporting a site for a client on the intranet. The site contains links to xml files. These xml files have a unique extension and are intended to be opened by a specific application. Using IE 8, we could support this by setting the option ‘Open files based on content, not file extension’ in Internet Options -> Security -> Custom Level. In IE 9, this option has been removed. Now these files open a new tab and display the xml.
Ideally, I’d like the file to just download through the download manager, but opening file in the application on the client machine would be acceptable as well. What is the best way to do this in IE 9? Is there a setting that I should adjust? Server side, I have tried adjusting the MIME type, but it seems that if I sent it to something unknown (e.g. application/octet-stream) IE determines the content. The last option I could think of would be to adjust the links such that they call an asp.net page that loads the contents of the xml into the response object but changes the header to contain Content-Disposition:"attachment;filename=file.ext”.
Any advice on the best way to solve this problem?
Content-Disposition:attachment is what you are looking for, yes. That is how you instruct browsers to download the file separately, and not try to display it.
You could use routing or rewriting to keep your file URLs, but have an ASHX handle the file so it can set that header. (don't use an ASPX; it's more than you need to just set some headers)
I think the work around that I was looking for was the fact that the 'Open files based on content, not file extension' option in IE8 was renamed, 'Enable MIME Sniffing' in IE9. But Andrew Barber's answer is the correct solution.