I am using Railo 3.0 for a web application (setup exactly the same as this excellent guide). I have a CFM page that serves up some old HTML files using the cfcontent tag. This content is in various character sets (all defined as meta tags in the HTML). The problem is that all my CFM pages are getting sent out with UTF-8 set in the HTTP response headers, and this overrides anything defined in the HTML. The pages therefore get displayed incorrectly in the browser.
How can I stop the charset being sent in the HTTP headers for CFM pages?
Notes:
I've removed the AddDefaultCharset entry from the default Apache config, and this means that static HTML pages are now served without any charset in the header, however this didn't help for CFM pages - AddDefaultCharset is bad, bad, bad
I know this is an old thread, but I have had a similar issue recently and overcame it using the underlying java servlet context. If you get hold of the ServletResponse you can call .reset(), which according to the Java docs says:
Clears any data that exists in the buffer as well as the status code and headers.
You'll need to rewrite ALL the headers from scratch, but it will clear the rogue charset header.
<cfset objResponse = GetPageContext().getResponse()>
<cfset objResponse.reset()>
This works in Railo. In CF (Adobe) I think you need to call getResponse() twice to get hold of the appropriate response object.
Hope that helps someone.
what charset are you trying to send the pages out as? you can force the charset of the page a couple of ways:
<cfprocessingdirective pageEncoding="windows-1252">
http://livedocs.adobe.com/coldfusion/8/htmldocs/help.html?content=Tags_p-q_13.html#2962107
<cfheader name="charset" value="windows-1252">
http://livedocs.adobe.com/coldfusion/8/htmldocs/help.html?content=Tags_g-h_07.html#3989067
Related
Is there a way to set up IIS to make all HTTP requests use HTTPS and avoid mixed content.
I realize that in page URLs can be rewritten or set up as protocol relative with the // at the beginning but I would like a solution that can deal with relative URLS in HTML and CSS like src="styles/style.css" and could work universally across many pages and all content.
im working on an app which fetches json from a website. everything is working properly and im using alamofire .
but for some reason, when i post new content on the website and the json file changes, alamofire doesnt get the new content. instead, it loads the content from the cache instead of redownloading the new content.
the only workaround to this is to clear the cache which is a way that i do not prefer since the user will have to download the content all over again at each view load.
so what im asking is, is there a way to notify the alamofire method about the new content and try to load the new content instead of having me to implement a method to clear the cache?
Alamofire uses the Foundation URL loading system, which relies on NSURLCache. The cache behavior for HTTP requests is determined by the contents of your HTTP response's Cache-Control headers. For example, you may wish to configure your server to specify must-revalidate:
Cache-Control: max-age=3600, must-revalidate
You should also make sure your server is specifying ETag and Content-Length headers to make it easy to tell when content has changed.
NSHipster's writeup on NSURLCache has a few good examples. If you're totally new to web caching, I recommend you read the very helpful section 13 of the HTTP 1.1 spec, and possibly also this caching tutorial.
I'm building a web server as an exercise. When I receive a raw request, it gets parsed into an simple syntax tree, and a response is built by evaluating this tree. My question this: When sending an HTTP Response, does the Content-Type field get set by taking the file extension of the requested resource and looking it up in a dictionary of MIME-types? A good example would be the anatomy of how the response for a favicon.ico is built. Any insight into this would be most helpful. Thanks.
By default, web server looks into file extension and select what kind of Content Type it should interpret the file as. However, server-side scripting can send custom header ( e.g. header() function of PHP ) to override the settings . For example, a JPEG can be interpreted as PNG if you send Content Type as image/png to web server with the following code:
header('Content-Type: image/png');
For non-file requests, the web server looks into custom header directly.
Web server maps extension with MIME type. As you tag apache, Apache uses AddType directive to identify file's MIME type, while IIS and other web servers have similar settings .
I have HTML pages that contain <a> tags with hrefs that point to PDF files. My Apache Web server serves them just fine, but the title, as shown in the Browser history, is of the file name. I would like to be able to set that title.
Perhaps there's a Header than can be set?
I don't want to write a script to serve the files as the server can handle Content-Encoding negotiation (e.g., for gzip), and do flow control, none of such do I want to re-create.
Here is an http header you can set.
Content-Disposition:inline; filename="*File name you want*";
I suspect the issue you are having is that the client browser is storing the file name in the history, which you cannot fix.
Last I checked, the title in the history came from the setting of the HTML page (not a header), so there should be no HTTP header field for the title.
I am no HTTP expert and do not know all the fields, but I do not remember there being a setting in any server that I have ever worked with to set the page's title (just the status code, protocol, etc.)
I created a PHP-Skript (e.g. download.php, filename doesn't matter) like this:
<?php
header("Content-Type: application/pdf");
header('Content-Disposition: inline; filename="'.addslashes($_REQUEST['title']).'"'); //filename doesn't set the browser title here, only when page is saved/downloaded
$content = file_get_contents($_REQUEST['filename']);
header('Content-Length: '.strlen($content));
echo $content;
In my setup (Windows 10; Apache 2.4.37; PHP 7.1.25) you can now do a request like this:
http://..../download.php/browser_title?filename=test.pdf
I tested this successfully in Chrome and Firefox.
Internet Explorer was not able to display a PDF-Document inline :-/.
Microsoft Edge also included the URL-Parameter in the title bar :-(.
I'm having an issue with a friends iWeb website - http://www.africanhopecrafts.org. Rather than pages viewing they want to download instead but they're all html files. I've tried messing with my htaccess file to see if that was affecting it but nothings working.
Thanks so much
Most likely your friend's web site is dishing up the wrong MIME type. The web server might be malconfigured, but the page can override the content-type responde header by adding a <meta> tag to the page's <head> like this:
<meta http-equiv="content-type" content="text/html" charset="ISO-8859-1" />
(where the charset in use reflects that of the actual web page.)
If the page is being served up with the correct content-type, the browser might be malconfigured to not handle that content type. Does the problem occur for everybody, or just you? IS the problem dependent on the browser in use?
You can sniff the content-type by installing Firefox's Tamper Data plug in. Fire up Firefox, start TamperData and fetch the errant web page via Firefox. Examining the response headers for the request should tell you what content-type the page is being served up with.