I'm using X-Content-Type-Options:nosniff security header on my project, but it broke my images on IE. All other file types work fine, except of images.
I suspect that IE is handling image differently that type specific in Content-Type header (i.e. image/jpeg). I assume it recognizes images as application/octet-stream as I'm returning array of bytes in my app logic.
One solution is to use nosniff for all content-types instead of images (image/jpeg/ image/png...).
Do you agree this is best solution for this case?
What type IE assumes for image when it is returned as byte array?
Thanks
Related
Like the first image, the meta tag is displayed correctly in inspect elements mode but incorrectly displayed in view page source mode as in the second image. Thank you for suggesting a solution to this problem.
I understood the answer:
Because, by default, the HTML encoding engine will only safelist the basic latin alphabet (because browsers have bugs. So we're trying to protect against unknown problems). The &XXX values you see still render as correctly as you can see in your screen shots, so there's no real harm, aside from the increased page size.
If the increased page size bothers you then you can customise the encoder to safe list your own character pages (not language, Unicode doesn't think in terms on language)
To widen the characters treated as safe by the encoder you would insert the following line into the ConfigureServices() method in startup.cs;
services.AddSingleton<HtmlEncoder>(
HtmlEncoder.Create(allowedRanges: new[] { UnicodeRanges.BasicLatin,
UnicodeRanges.Arabic }));
Arabic has quite a few blocks in Unicode, so you may need to add more blocks to get the full range you need.
I have a strange problem.
On a website for my client, I'm showing some mp4 files using the HTML5 video element. The videos that are visible on the page while loading do show up on mobile devices without any problems.
When I try to change the source of a video element (after an AJAX request), the video element shows a black screen. The new video source I changed could be exactly the same as one that was already shown on page load, but after updating the src parameter it just won't show..
Already tried checking the mp4 encoding (which is H.264), the content-type in the server response-headers is correct (video/mp4) and the server seems to return "206 Partial Content". Also, gzip encoding for mp4 files is off.
If I check the remote debugger in Safari (inspecting Safari on an iPad), I get the error "An error occurred trying to load the resource". Below you find the response headers:
HTTP/1.1 206 Partial Content
Content-Type: video/mp4
ETag: "23f72-5a4561b99803e"
Last-Modified: Tue, 28 Apr 2020 09:03:40 GMT
Content-Range: bytes 0-147313/147314
Accept-Ranges: bytes
Date: Wed, 29 Apr 2020 05:13:12 GMT
Content-Length: 147314
Keep-Alive: timeout=5, max=84
Connection: Keep-Alive
Server: Apache
Does anyone have an idea what could be causing this issue?
Thanks!
The documentation for this can be a bit confusing - it can look like it is not possible to dynamically change the source (https://html.spec.whatwg.org/multipage/embedded-content.html):
Dynamically modifying a source element and its attribute when the element is already inserted in a video or audio element will have no effect. To change what is playing, just use the src attribute on the media element directly, possibly making use of the canPlayType() method to pick from amongst available resources. Generally, manipulating source elements manually after the document has been parsed is an unnecessarily complicated approach.
However, it can be changed and the code snippet below should work reliably cross browser - the video.load() line is key as it actually makes sure the new source is inserted. You can experiment by commenting out this line and seeing the difference:
var video = document.getElementById('video');
var source = document.createElement('source');
source.setAttribute('src', 'http://commondatastorage.googleapis.com/gtv-videos-bucket/sample/ForBiggerBlazes.mp4');
video.appendChild(source);
video.play();
function changeSource() {
video.pause();
source.setAttribute('src', 'http://clips.vorwaerts-gmbh.de/VfE_html5.mp4');
video.load(); //This step is key
video.play();
}
<h1>Video source change test</h1>
<p>
<button id="sourceButtom" onclick="changeSource()">Click me to change the video source.</button>
<p>
<video id="video" width="320" controls height="240"></video>
The above is based on the excellent answer here: https://stackoverflow.com/a/18454389/334402
My app allows for a text file to be emailed to other users with or without images and audio. When there's no images or audio, then the app sends the text file "as is" with a custom extension (e.g. text.xxx). When there's audio and images, the app zips the text file along with the images and audio into a file named something like text.xxx.zip.
Prior to iOS 6 this worked fine. Pre iOS 6, the app was given the URL of the text.xxx.zip file. Now, with iOS 6, it appears that the file is already unzipped by Mail, and only the text.xxx is sent to the openURL handler.
Does anyone out there have any experience with this? Suggestions for a better approach? I'm thinking I'll need to come up with a unique extension for the zipped case...
So after pounding my head on this for the last 24 hours or so, this is what "solves" the problem:
1) Change any existing attachment filenames from test.xxx.zip to test.zip. It looks iOS6 Mail is assuming that anything of the form filename.xxx.zip, is really just a compressed version of filename.xxx. (Maybe that's a standard somewhere?) Also noted that if I changed the filename to test.yyy.zip it then said it couldn't open the attachment. (presumably since no one registered for the ".yyy" extension).
2) Rewrite code to not use .zip extension in the future to prevent similar issues.
I also discovered that for multiple document types (e.g., .xxx, .zzz) you must specify a different mime type for each in the UTI declaration - otherwise Mail appends the first UTI extension it finds to the object and then calls openURL. So, in other words, if you're set up to handle a flat file (.xxx) and a zip file (.zzz), but you use the same mime type (e.g. application/myappname) and "xxx" is defined first, when openURL is called for your file "test.zzz", it will actually pass it to openURL as "test.xxx".
I have a selenium test I am creating. The application creates a pdf for the user. I want to know how to test that a url returns a pdf file. I don't really care what is in the pdf, just that one got created.
FYI - The url does not container .pdf
http://www.url.com/printp/something.php?pld=b8eiub9w6ar2am1i
Alternatively, make a HEAD request first to check if the url is created, then inspect content_length header, which should be nonzero size, or whatever is reasonable minimum size in your case.
Can you test if //meta[contains(#http-equiv,Content-Type)][contains(#content,pdf)] exists!
I did not test !
I'm getting a 206 on some images, and I'm not quite sure why (thus how to solve it).
Basically all the images are being called through the css file.
background-image: url(Images/i-Background.jpg); //works
background-image: url(Images/i-NavHeader-Blank.png); //doesn't work
However firebug is showing two different sets of request headers for the request, but be damned if I can figure out what could be causing that. I know that the 206 is due to the Range being set, and for some reason on the non-working ones it is set to Range bytes=0-
where as the working ones have no Range header.
Is there any reason why some have different request headers to others?
Thanks,
Psy
Ok, worked it out, was to do with filezilla deciding the pngs needed to be uploaded as ASCII rather than binary, and the server doesn't like ASCII pngs :p