I have a file proxy IHttpHandler to ensure authentication and to log requests. It works fine on the development server and IIS 6. In IIS 7, I have two problems:
Microsoft Office (Word, Excel...) sends WebDAV requests with OPTION and PROPFIND verbs. ASP.NET throws an exception since it doesn't support them. Is there any way to disable these verbs at the IIS level so that it never reaches ASP.NET? I'm guessing it would be returning a 405 Method Not Allowed error (http://en.wikipedia.org/wiki/List_of_HTTP_status_codes#4xx_Client_Error).
IIS 7 turns on chunked encoding. In that case the Content-Length header is not valid and apparently IIS 7 removes it: http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.4.4. However, it also removes the Content-Type header, causing the files to show up as text in the browser. So how can I stop IIS 7 from removing Content-Type, OR how do I turn off chunked encoding for this one page? Below are the response headers for you to compare.
Development server response:
HTTP/1.1 200 OK
Server: ASP.NET Development Server/9.0.0.0
Date: Thu, 23 Dec 2010 17:57:09 GMT
X-AspNet-Version: 2.0.50727
Content-Length: 68096
Content-Disposition: inline; filename=test.doc
Cache-Control: private
Last-Modified: Thu, 23 Dec 2010 09:14:18 GMT
Content-Type: application/msword
Connection: Close
IIS 7 response:
HTTP/1.1 200 OK
Cache-Control: private
Transfer-Encoding: chunked
Last-Modified: Thu, 23 Dec 2010 09:30:31 GMT
Server: Microsoft-IIS/7.5
Content-Disposition: inline; filename=test.doc
X-AspNet-Version: 2.0.50727
X-Powered-By: ASP.NET
Date: Thu, 23 Dec 2010 17:57:59 GMT
My question on chunked encoding was inaccurate. I had made one small change on my development machine: I added Content-Length. On the development machine it didn't make a difference--it always worked. In IIS 7, adding Content-Length actually disabled chunked encoding and everything worked as expected.
For the WebDAV requests, IIS 7 doesn't send them through to ASP.NET so we're fine. The development server does, however. I saw a suggestion to add the DefaultHttpHandler to handle them, but on the development server that means the raw aspx page is served.
Related
While optimizing the caching-behaviour of our website, I noticed that a whole lot of if-none-match-requests are sent to our site. As far as I understand caching, this should not be the case as long as the cache is still valid.
One particular request generates the following response-header:
HTTP/1.1 200 OK
Cache-Control: public, max-age=25920000
Transfer-Encoding: chunked
Content-Type: application/javascript; charset=utf-8
Content-Encoding: gzip
Expires: Thu, 04 Feb 2016 17:20:09 GMT
Last-Modified: Mon, 01 Jan 2001 23:00:00 GMT
ETag: W/"0"
Vary: Accept-Encoding
Server: Microsoft-IIS/8.5
X-AspNet-Version: 4.0.30319
Date: Fri, 10 Apr 2015 16:20:09 GMT
As you can see, the cache should be valid for 300 days. The way I understand it, the browser should use its cache directly during that period. Only after this period is over, it should issue a request with the header if-none-match.
But browsers seem to ignore that and send this if-none-match -request each and every time the page is loaded just to receive a 304-response ("Not Modified").
What do I need to change to keep browsers from sending these useless requests?
Yes, while the cache is fresh browsers should use a local copy without revalidation. However, this is not guaranteed. For example, when users use the Refresh button browsers make requests to the origin server anyway.
There is a Cache-Control: immutable, max-age=… extension that tells browsers you really really mean they should use the cached resource without contacting the server.
I'm having trouble with the server-sent events transport in SignalR when the client is behind a web proxy. From the user's experience, SignalR tries to make the serverSentEvents connection, that fails so 5 seconds later it falls back to longPolling. I'm using Chrome 38 (Firefox 31 ESR also fails to connect with SSE) and have the webSocket transport disabled for other reasons.
Apparently, the proxy is rewriting the HTTP 1.1 Transfer-Encoding chunks (merging two chunks into one). The Notes section of the SSE spec advises "Authors are also cautioned that HTTP chunking can have unexpected negative effects on the reliability of this protocol." So, right now that's my best guess. Oh, and when I put a breakpoint in the SingalR JavaScript client's EventSource message event handler, it never gets hit.
Can anyone confirm that this chunking change is likely the cause of the connection dropping?
Is there any way to disable chunking on the server side just for this transport?
Here's what the TCP response to the GET /signalr/connect request looks like:
as sent from the server:
HTTP/1.1 200 OK
Cache-Control: no-cache
Pragma: no-cache
Transfer-Encoding: chunked
Content-Type: text/event-stream
Expires: -1
Server: Microsoft-IIS/7.5
X-Content-Type-Options: nosniff
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET
Date: Wed, 05 Nov 2014 15:49:29 GMT
13
data: initialized
2f
data: {"C":"d-3B309D97-E,1|F,0","S":1,"M":[]}
0
as received by the client:
HTTP/1.1 200 OK
Cache-Control: no-cache
Pragma: no-cache
Transfer-Encoding: chunked
Content-Type: text/event-stream
Expires: -1
Server: Microsoft-IIS/7.5
X-Content-Type-Options: nosniff
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET
Date: Wed, 05 Nov 2014 15:49:29 GMT
42
data: initialized
data: {"C":"d-3B309D97-E,1|F,0","S":1,"M":[]}
0
I'm getting reports of sporadic instances where users in various browsers get a 302 page, but instead of automatically redirecting, the browser just displays the Object moved to here HTML sent by the browser. What could possibly cause this? If it were one browser on one machine, I'd blame a bad installation or something, but I've had a handful of reports, just in the past couple of days, from a number of machines and browsers, so I'm nervous that something is actually wrong with the HTTP Response, even though it couldn't be that wrong or the app wouldn't work almost everywhere else, as it does.
Anyway, here's the Response packet:
HTTP/1.1 302 Found
Cache-Control: private
Content-Type: text/html; charset=utf-8
Location: /nextpage
Server: Microsoft-IIS/8.5
X-AspNet-Version: 4.0.30319
Set-Cookie: cookiename={...data...}; path=/
Date: Fri, 10 Oct 2014 14:31:44 GMT
Content-Length: 124
<html><head><title>Object moved</title></head><body>
<h2>Object moved to here.</h2>
</body></html>
Am I missing anything here?
I have a production OrchardCMS site that is running fine.
Today I copied all of the files from that site to a local server so I could use it for staging and testing changes before deployment. One other little change I made is changed the Orchard instance to use a local full SQL instance instead of Sql CE. (Which is something I will also do in production in the next few days.)
The migration has worked fine. I can load the Orchard instance using localhost on port 2764 (the one I assigned) and it works perfectly ... exactly as on production.
I setup port forwarding on my router to connect to this staging/testing server when connecting on port 2764. (And also created an inbound rule on the local server).
When I access the site on that port from a remote computer, it loads the CONTENT but does not fetch any of the files (CSS, JS, etc.) So I see content but it is raw unformatted html.
I loaded the page in fiddler and it shows a header like this for the sessions...
HTTP/1.1 302 Found
Location: /Users/Account/AccessDenied?ReturnUrl=%2fThemes%2fBootstrap%2fStyles%2fbootstrap.min.css
Server: Microsoft-IIS/7.5
X-Powered-By: ASP.NET
Date: Mon, 03 Dec 2012 04:38:01 GMT
Content-Length: 205
and then ...
GET /Users/Account/AccessDenied?ReturnUrl=%2fThemes%2fBootstrap%2fStyles%2fbootstrap.min.css HTTP/1.1
HTTP/1.1 200 OK
Cache-Control: no-cache, no-store, must-revalidate
Pragma: no-cache
Content-Type: text/html; charset=utf-8
Content-Encoding: gzip
Expires: -1
Vary: Accept-Encoding
Server: Microsoft-IIS/7.5
X-AspNetMvc-Version: 3.0
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET
Date: Mon, 03 Dec 2012 04:38:01 GMT
Content-Length: 2179
If I login to the site (I can still see the login button and subsequent login page) I am successfully logged in and then the website performs perfectly normally...until I log out again.
So the bottom line...anonymous users can see content but OrchardCMS (or IIS ... or both?) will not fetch any of the files it seems.
Any ideas on the cause of this? Thanks for your help.
Seth
It turns out it was a straight up NTFS permissions thing. Anonymous Users were using the IUSR identity which I had not given any permissions. I changed that to use the APP POOL identity and all has been well. I suppose I could also have given read permissions to IUSR.
At random this output it occurring at the top of the page. Site is installed on a lot of servers issue only happens on one server.
HTTP/1.1 200 OK Date: Mon, 24 May 2010 04:18:30 GMT Server:
Microsoft-IIS/6.0 X-Powered-By: ASP.NET X-AspNet-Version: 2.0.50727
Cache-Control: private Content-Type: text/html; charset=utf-8
Content-Length: 39611
Use a diagnostics tool such as Fiddler to work out exactly what server its happening on, and what page is being requested, what is being responded with, etc. Then replay that request to another server. Should be able to sort out the problem from there.