Having a strange issue - we have a page that uses a query string to get some information, this query string happens to contain the word set. When this happens, the page returns a 406 error (Client browser does not accept the MIME type of the requested page.)
The URL looks like example.com/folder/file.asp?variable=sunset boulevard. If I change the space to %20 it still returns 406.
On my local machine running IIS 5.x this doesn't happen, on our test server running IIS 7.x this doesn't happen, only on our production server running IIS 7.x over SSL. Note however that a self signed certificate on my local machine over SSL still doesn't produce the error.
So my question is, what does the set keyword in the URL tell IIS to do and is there an easy way to avoid it happening? I would like to avoid changing the space to a different character if possible.
Does your server have additional filters installed? Smells like the work of an agressive filter designed to prevent certain types of attack.
Related
IIS7 serving .Net web application (simple database site).
I have a weird issue where the backgroundimage(URL) property of a element will be served as "http:\localhost" instead of "http:\servername". This is a problem because when a user connects to my site, "localhost" would be their workstation, not the IIS server. So the image (in this case a button) is blank.
The issue is intermittent, recycling the application pool seems to fix the issue for a time and then it comes back. IIS server also runs a SQL instance which eats ~28/36GB RAM.
Anyone ever seen anything like this?
In order to fix this you need to search for all locations where "http:\localhost" is hardcoded in your web app and replace it with a dynamic path. Even though localhost can work in your code if it is relative to the server, there are times when it will not work, such as in a link. You should get in the habit of never hardcoding your urls.
If you are using MVC -
value = Url.Content("~/Images/MyImage.png");
If you are using Forms -
value = ResolveUrl("~/") + "Images/MyImage.png"
Or relative pathing -
value = "~/Images/MyImage.png"
I'm working with MicroStrategy 10.3, hosted on IIS 7.5. I'm using their
URL API to run a document, and change the value of a drop down selector.
IIS is tinkering with my query parameters though, via a 302 redirect. This URL:
https://server/MicroStrategy/asp/Main.aspx?Server=XXX&Project=XXX&evt=2048001&src=Main.aspx.2048001&maxWait=-1&documentID=XXX&evt=2048084&src=Main.aspx.oivm.rwb.2048084&ctlKey=XXX&elemList=hXX;XXX&evtorder=2048001%2c2048084&2048084=1&2048001=1
is being 302'ed to:
https://server/MicroStrategy/asp/Main.aspx?Server=XXX&Project=XXX&evt=2048001%2C2048084&src=Main.aspx.2048001%2CMain.aspx.oivm.rwb.2048084&maxWait=-1&documentID=XXX&ctlKey=XXX&elemList=hXX%3BXXX&evtorder=2048001%2C2048084&2048084=1&2048001=1
(The two distinct evt and src are being combined, and MicroStrategy is complaining that 'Event ID 2048001,2048084 is illegal'.)
Does IIS do this type of thing out of the box? It certainly seems unlikely. I can't see any custom HTTP redirects in IIS Manager for the application.
IIS was most definitely not the culprit.
MicroStrategy was generating the 302 redirect itself, subsequent to an automated login. You would think that an enterprise application wouldn't rewrite its own URL such that it causes an error, but you'd be wrong.
I resolved the issue by manually adding a login event, and URL-encoding the two events I wanted to call into the target key:
https://server/MicroStrategy/asp/Main.aspx?Server=XXX&Project=XXX&evt=3054&src=Main.aspx.3054&target=evt%3D2048001%26src%3DMain.aspx.2048001%26maxWait%3D-1%26documentID%3DXXX%26evt%3D2048084%26src%3DMain.aspx.oivm.rwb.2048084%26ctlKey%3DXXX%26elemList%3DhXX%3BXXX%26evtorder%3D2048001%252c2048084%262048084%3D1%262048001%3D1
I have read a few answers to try and find a solution to a ridiculous problem.
I dont have access to a server that I can log on to access phpmyadmin,
What is supposed to happen is that the web url is supposed to be viewed via https, and in most cases this happens.
Except for a particular PC I have at home and it never seems to open in https. Why this is happening on this given machine is completely unknown.
Is there a way I can set up a rule on my local machine that will ALWAYS convert http://pathtomysite.com to https://pathtomysecuresite.com, (possibly via the 'hosts' entry (and yes it is a windows machine running win10).
I could do this on the web server itself, I know how to do this, but the problem is, I don't have, nor am I allowed to have, access to the database server to update the .htaccess or webconfig.xml on the server. (I am 99% sure its Apache, not nginx or IIS).
Any help is allows gratefully received.
I recall the syntax of a hack when routing a request to local IIS but I cannot recall what it does. It popped up randomly in the browser during a debug session this morning and when I recognized it, I went looking for documentation on the technique to refresh my memory and came up blank.
So, if you were to enter
http://localhost:8080 and
http://localhost.:8080
into two separate browsers, what difference would you expect "the dot" to make?
I found the explanation (and when I recalled that Fiddler involved, I also recalled what the hack did)
Fiddler and IE7
It isn't related to IIS; It's a workaround for Internet Explorer to force the browser to not bypass a proxy. Since Fiddler is implemented as a proxy, http://localhost:8080 will completely bypass it but http://localhost.:8080 will not bypass the proxy, allowing monitoring tools to capture traffic.
Internet Explorer (7 and 8, I think) is written to bypass proxy servers for resolving "localhost" resources. Appending a trailing dot to "localhost" provides a valid DNS name that does not match the rules that "Old IE" uses for this bypass logic. Internally, the trailing dot gets trimmed from name resolution and you force IE to not execute its internal logic that bypasses the proxy server.
From what I understand, this was changed in IE9.
I have a site which is completely on https: and works well, but, some of the images served are from other sources e.g. ebay, or Amazon.
This causes the browser to prompt a message: "this website does not supply identity information"
How can I avoid this? The images must be served from elsewhere sometimes.
"This website does not supply identity information." is not only about the encryption of the link to the website itself but also the identification of the operators/owners of the website - just like it actually says. For that warning (it's not really an error) to stop, I believe you have to apply for the Extended Validation Certificate https://en.wikipedia.org/wiki/Extended_Validation_Certificate. EVC rigorously validates the entity behind the website not just the website itself.
Firefox shows the message
"This website does not supply identity information."
while hovering or clicking the favicon (Site Identity Button) when
you requested a page over HTTP
you requested a page over HTTPS, but the page contains mixed passive content
HTTP
HTTP connections generally don't supply any reliable identity information to the browser. That's normal. HTTP was designed to simply transmit data, not to secure the data it transmits.
On server side you could only avoid that message, if the server would start using a SSL certificate and the code of the page would be changed to exclusively use HTTPS requests.
To avoid the message on client side you could enter about:config in the address bar, confirm you'll be careful and set browser.chrome.toolbar_tips = false.
HTTPS, mixed passive content
When you request a page over HTTPS from a site which is using a SSL certificate, the site does supply identity information to the browser and normally the message wouldn't appear.
But if the requested page embeds at least one <img>, <video>, <audio> or <object> element which includes content over HTTP (which won't supply identity information), than you'll get a so-called mixed passive content * situation.
Firefox won't block mixed passive content by default, but only show said message to warn the user.
To avoid this on server side, you'd first need to identify which requests are producing mixed content.
With Firefox on Windows you can use Ctrl+Shift+K (Control-Option-K on Mac) to open the web console, deactivate the css, js and security filters, and press F5 to reload the page, to show all the requests of the page.
Then fix your code for each line which is showing "mixed content", i.e. change the appropriate parts of your code to use https:// or, depending on your case, protocol-relative URLs.
If the external site an element is requested from doesn't use a SSL certificate, the only chance to avoid the message would be to copy the external content over to your site so your code can refer to it locally via HTTPS.
* Firefox also knows mixed active content, which is blocked by default, but that's another story.
Jürgen Thelen's answer is absolutely correct. If the images (quite often the case) displayed on the page are served over "http" the result will be exactly as described no matter what kind of cert you have, EV or not. This is very common on e-commerce sites due to the way they're constructed. I've encountered this before on my own site AND CORRECTED IT by simply making sure that no images have an "http" address - and this was on a site that did not have an EV cert. Use the ctrl +shift +K process that Jürgen describes and it will point you to the offending objects. If the path to an object is hard coded and the image resides on your server (not called from somewhere else) simply remove the "http://servername.com" and change it to a relative path instead. Correct that and the problem will go away. Note that the problem may be in one of the configuration files as well, such as one of the config.php files.
The real issue is that Firefox's error message is misleading and has nothing to do with whether the SSL is an EV cert or not. It really means there is mixed content on the page but doesn't say that. A couple of weeks ago I had a site with the same problem and Firefox displayed the no-identity message. Chrome, however, (which I normally don't use) displayed an exclamation mark instead of a lock. I clicked on it and it said the cert was valid (with a green dot), it was a secure connection (another green dot), AND had "Mixed Content. The site includes HTTP resources" which was entirely accurate and the source of the problem (with a red dot). Once the offending paths were changed to relative paths, the error messages in both Firefox and Chrome disappeared.
For me, it was a problem of mixed content. I forced everything to make HTTPS requests on the page and it fixed the problem.
For people who come here from Google search, you can use Cloudflare's (free) page rules to accomplish this without touching your source code. Use the "Always use HTTPS" setting for your domain.
You can also transfrom http links to https links using url shortener www.tr.im. That is the only URL-shortener I found that provides shorter links through https.
You just have to change it manually from http://tr.im/xxxxxx to https://tr.im/xxxxxx.