2

Does IIS have a secret, unlogged, transparent, case-sensitive proxy built into it?

A file exists on the web-server:

GET http://www.stackoverflow.com/javascript/ModifyQuoteArea.js HTTP/1.1
Accept: text/html, application/xhtml+xml, */*
Accept-Language: en-US
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
Host: www.stackoverflow.com


HTTP/1.1 200 OK
Connection: Keep-Alive
Content-Length: 29246
Date: Mon, 07 Mar 2011 14:20:07 GMT
Content-Type: application/x-javascript
ETag: "5a0a6178edacb1:1c51"
Server: Microsoft-IIS/6.0
Last-Modified: Fri, 02 Tue 2010 17:03:32 GMT
Accept-Ranges: bytes
X-Powered-By: ASP.NET

...

Problem is that a changes made to the file will not get served, the old (i.e. February of last year) version keeps getting served:

HTTP/1.1 200 OK
Connection: Keep-Alive
Content-Length: 29246
Date: Mon, 07 Mar 2011 14:23:07 GMT
Content-Type: application/x-javascript
ETag: "5a0a6178edacb1:1c51"
Server: Microsoft-IIS/6.0
Last-Modified: Fri, 02 Tue 2010 17:03:32 GMT
Accept-Ranges: bytes
X-Powered-By: ASP.NET

...

The same old file gets served, even though we've:

  • renamed the file
  • deleted the file
  • restarted IIS

The request for this file does not appear in the IIS logs (e.g. C:\WINNT\System32\LogFiles\W3SVC7\)

And this only happens from the outside (i.e. the internet). If you issue the request locally on the server, then you will:

  • get the current file (file there)
  • 404 (file renamed)
  • 404 (file deleted)

But if i change the case of the requested resource, i.e.:

GET http://www.stackoverflow.com/javascript/MoDiFyQuOtEArEa.js HTTP/1.1
Accept: text/html, application/xhtml+xml, */*
Accept-Language: en-US
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
Host: www.stackoverflow.com

Note: MoDiFyQuOtEArEa.js verses ModifyQuoteArea.js

Then i do get the proper file (or get the 404 as i expect if the file is renamed or deleted).

But any subsequent changes to the file will not show up until i change the case of the file i'm asking for.

The IIS logs show no activity when the web-site serves up one of the mysterious cached files. Requests for other (i.e. ASP) files (or using the change-requested-resource-case-to-bypass-transparent-cache trick) do show up in the IIS logs, and they show the proper source client IP address (i.e. not the address of some mysterious intermediate proxy).

  • Since the file doesn't exist on the hard drive anymore, i conclude that there is a proxy.
  • The requests serviced from this proxy are not logged in the IIS logs.
  • The requests for new files are logged, and from the client IP, not a proxy IP.
  • The proxy is case sensitivie.

This does not sound like something Microsoft, or IIS, would do: - a transparent proxy? - case-sensitivie? - unlogged? - surviving restarts of IIS? - surviving in a cache for hours?

can't believe that our customer's IIS are doing these things. i'm assuming there is some other transparent proxy in front of IIS.

Or, does IIS have a:

  • transparent,
  • unlogged,
  • case-sensitive,
  • memory based

proxy, that caches content for at least 7 hours?

4 Answers 4

2

If the request does not show up in the IIS logs then it is being served by a cache somewhere, either the client's local cache or a cache (proxy) somewhere in the request chain.

Look at the response headers for a request on the client end and see if there are any Via: headers in there. A Via: header indicates that there is a proxy in the chain and there should be one header for each proxy in the chain (assuming the proxies are behaving). If you see one or more then it's a good chance the content is being served from a cache.

4
  • You can see the response headers quoted in the question.
    – Ian Boyd
    Mar 7, 2011 at 15:34
  • @Ian Of course...sorry for the ignorance. This is not native IIS behavior, it has to be a special http handler in the app or a cache somewhere in the stream. Can you find out from your or your client's ISP if they are running one? Also, is this the case for any browser on the client?
    – squillman
    Mar 7, 2011 at 16:27
  • Well if it sounds crazy to you, and it sounds crazy to me, then it's safe to say that it's crazy.
    – Ian Boyd
    Mar 9, 2011 at 3:04
  • 1
    Everyone there swears there is no cache involved. We swear everyone there is wrong.
    – Ian Boyd
    Mar 11, 2011 at 14:28
1

Before I don my tinfoil hat and declare that there must be a super-secret proxy that nobody knows about, I'd ask the client to check their browser settings. If they're using IE, this sounds somewhat like "Check for newer versions of stored pages: Never" (could also be "Every time I start IE" if the client didn't already restart IE as part of the troubleshooting).

2
  • It's not just the client, we can do it here. i can do it from home. i can do it from IE and Chrome. i issue the HTTP GET request manually using Fiddler. i can issue the requests directly with TELNET.
    – Ian Boyd
    Mar 11, 2011 at 14:26
  • @Ian OK, tinfoil hat time. But if you can replicate this from home, then the only constants in the equation are your server, network, and ISP. This calls for a packet capture starting from the server level to see if the server receives the request. If not, then we're down to network and ISP.
    – DerfK
    Mar 11, 2011 at 16:10
1

Try curl -v http://www.stackoverflow.com/javascript/ModifyQuoteArea.js, if you still see old version theres a misconfigured/not HTTP compliant cache in the path from client to server. If you see current version your browser will be blamed

0

Sooo the answer is "it shouldn't".

Longer answer in the form of a question: the proxy behaviour you're showing there is very proxy-like, in that the hostname is part of the request. Are you treating the server like a proxy, or are you just catching the traffic from a proxy?

Typically, when clients request content they request a relative URL and supply a Host: header.

A client asks a proxy server for http://fullsomethingname.fqdn.com only when the target is configured as a proxy, and I've had to debug weird behaviour based on that before.

So from this, we can say with some surety that you've a proxy somewhere in the mix. Fiddler, which works as a proxy, counts.

I'd suggest, like Ochoto, trying Curl or WFETCH or WGET or any other simple uninterrupted-by-WinInet-or-IE's-browser-settings-or-proxy-cache client to be absolutely certain.

Actually, if you want absolute certainty:

  • Network capture running on the client
  • Simultaneous network capture on the server
  • Use of a browser client to request said content
  • Use of a non-browser client to request same content
  • If you had IIS 7, FREB logging for the URL would be so really fantastically nice
  • Ideally, the ability to step through the web server while it processes each extension; otherwise, something like IISTrace

If you really want, you can throw in HTTP.SYS tracing as well, just for good measure.

If

  • you see the request hit the server, and
  • the server send a response, and
  • that response is categorically Not Logged by the server, and
  • no ISAPI filters exist that might've decided that logging was so 1999, or
  • just choked and
  • haven't been molested by antivirus in some strange that-file-handle-is-valid-no-it-isn't-ha-got-you-it-is-after-all way, and
  • no exceptions occurred in managed handlers that shouldn't be running for static files but for some reason are still script mapped into handling them

Then, then, then then, um, oh sorry, I've lost my train of thought.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .