Archives
-
How to detect if the new HTML5 File Upload progress information is available in your browser
HTML5 has a some new File Upload features added to it must notably upload progress notifications while the file is being posted to the server through the XMLHttpRequest Level 2 (XHR2) object (http://www.w3.org/TR/XMLHttpRequest2/#event-xhr-progress).
Keep in mind that XMLHttpRequest Level 2 is not really HTML5 but as mentioned in this article http://www.html5rocks.com/en/tutorials/file/xhr2/, it is part of the core platform improvements and therefore frequently gets included under the HTML5 name umbrella:
One of the unsung heroes in the HTML5 universe is XMLHttpRequest. Strictly speaking XHR2 isn't HTML5. However, it's part of the incremental improvements browser vendors are making to the core platform.
Chrome, Firefox, Safari, and IE10 all support the new XHR2 progress events but unfortunately IE9 does not so you will need to check for them and fall back to something like SWFUpload to give you progress information while your file is posting to the server if the XHR2 object is not available.
But how do you test to see if the browser supports the new features of XMLHttpRequest Level 2 (XHR2) for progress information?
There is an interesting Modernizr thread here which talks about the various ways to test for it. In the end all you need to test for is the existence of window.FormData.
If you want to add an XHR2 test into Modernizr you can do it like this:
Modernizr.addTest('xhr2', 'FormData' in window);
if (Modernizr.xhr2) {
alert('File upload progress supported');
} else {
alert('No file upload progress support');
}Or you can just do it by running your own check without Modernizr:
if (!!window.ProgressEvent && !!window.FormData) {
alert('File upload progress supported');
} else {
alert('No file upload progress support');
}Note: Technically the test for window.ProgressEvent being undefined is not necessary as shown in the above Modernizr thread but I left it in just for my own knowledge.
-
You are not authorized to view this page due to invalid authentication headers.
I have been working through an authentication issue and making changes to IIS to debug the problem and then ran into the following IIS error:
HTTP Error 401.2 - Unauthorized
You are not authorized to view this page due to invalid authentication headers.
It took me a while to figure out what the problem was and in the end the cause was already listed in the “Most likely causes” section of this error page:
Most likely causes:
- No authentication protocol (including anonymous) is selected in IIS.
- Only integrated authentication is enabled, and a client browser was used that does not support integrated authentication.
- Integrated authentication is enabled and the request was sent through a proxy that changed the authentication headers before they reach the Web server.
- The Web server is not configured for anonymous access and a required authorization header was not received.
- The "configuration/system.webServer/authorization" configuration section may be explicitly denying the user access.
My issue is that I had been debugging an issue with Windows Authentication and I had disabled Anonymous Authentication and enabled Windows Authentication for this website in IIS (I know you are not supposed to have both Forms Authentication and Windows Authentication enabled at the same time... this was for a test).
When I had finished I thought I had reset everything back but I forgot to enable Anonymous Authentication. Just enabling Anonymous Authentication resolved the issue.
-
Show detailed Classic ASP error messages in IIS7 for both local and remote requests
In IIS7 you have to enable sending the detailed error message for Classic ASP. You can do this by configuring Classic ASP in IIS7:
And then setting the “Send Errors to Browser” setting to true:
Now you will get the detailed Classic ASP error message when an error occurs in your Classic ASP pages. But these will only show for local requests. Remote requests will still display the standard IIS 500 - Internal Server Error:
Not sending detailed error messages for remote requests is the default since it is a good idea for remote requests not to see the full error details (it could expose sensitive data to the Internet). But if you need to see it, such as on an internal testing server, follow these instructions to have IIS send the detailed error message for remote requests too.
In IIS go to the Error Pages:
Then on the right click on the Edit Feature Settings...
In the Edit Error Pages Settings dialog is where you choose to send for both local and remote requests. The second option button is what needs to be selected to have the detailed errors returned for both local and remote requests. The bottom option is what is on by default – where detailed error messages are only sent for local requests.
Keep in mind that it is not recommended to send detailed errors for remote requests since this could expose sensitive information to the Internet.
