I have a problem where a request with the OPTIONS verb fails with HTTP response code 404. After inspecting the logs, the issue came down to UrlScan 3.1, which blocks this verb by default. Removing the UrlScan from ISAPI fileters in IIS fixes the problem, however the UrlScan needs to be on the system.
As per UrlScan documentation (https://support.microsoft.com/en-us/kb/326444), I've added the OPTIONS verb to the [AllowVerbs] section of the UrlScan.ini file, checked that the UseAllowVerbs is set to 1 and restarted the IIS (also tried rebooting the server). However, this didn't fix this issue. I've tried removing all of the verbs from the allowed list just to see if that would have any effect, but nothing changed.
So, the question is why would UrlScan not take the new configuration?
Thank you!
I hope you might have found a solution. I went through the same problem today and what I did was checking url scan logs to see that 'Rejected disallowed+header request+headers transfer-encoding'. As a solution to this, added ; before transfer-encoding in [DenyHeaders] so that it will be commented. You might also be facing some other violation so therefore I suggest you to have a look on logs.
It's important you do a IISReset after changes rather than just a restart.
Spending a whole week, after all the following setting worked !
and finally saved.
Removing the UrlScan from ISAPI fileters in IIS fixes the problem, however the UrlScan needs to be on the system.
Related
I'm trying to disable the IIS localhost from Windows, without success. The only thing I'm finding is, that you have to disable the IIS option that's found in the Windows-Features. I disabled it and restarted my computer multiple times, but each time the localhost is still the default IIS...
Is there anything else I can do? I'm a complete newbie on this topic, so please tell me if there's information missing in my question.
Also tried the advice in this article, without success. The terminal does say, that the service has stopped, but localhost is still the Windows IIS. https://www.names.co.uk/support/1607-how_do_i_stop_iis_via_command_prompt_.html
Seems clearing the browser cache solved the problem.
I have an ASP.NET MVC5 website and I have installed Glimpse.MVC5 using nuget. The website is running the latest version of the Sitecore CMS (7.2 rev. 140314). I haven't changed the Glimpse configuration at all apart from adding logging.
When I go to the homepage of the website (after enabling Glimpse) I can't see the HUD. The following is the last line in the Glimpse log:
2014-04-24 15:19:01.6043 | DEBUG | Apparently GlimpseRuntime has not
yet initialized this request. This might happen in case you're doing
something specific like mentioned in this issue:
https://github.com/Glimpse/Glimpse/issues/703 . Either way, Glimpse
will be disabled to prevent any further non-deterministic behavior
during this request.
I've had a look at the link but I can't see that it applies to my situation. There are no NullReferenceException's in the log.
I have tested Glimpse.MVC5 with a vanilla ASP.NET MVC5 website on my machine and that worked fine so I'm tempted to assume that it's something to do with Sitecore.
Any ideas what could be wrong or ideas on how to identify the issue?
The solution mentioned in this post on the Glimpse issue tracker solved the problem.
Sitecore does it's own HttpModule stuff which seems to
cause issues.
In order to fix this, you need to move the Glimpse HttpModule
definition before the Sitecore modules in the Web.config.
The reason why you are still not seeing the HUD is explained by that log message as well.
Somehow during the execution of the request, a new HttpContext is created or used which means you'll loose the request initialization that Glimpse did at BeginRequest. As part of that initialization, items are being stored in the HttpContext.Items collection for which Glimpse will look during request monitoring.
The message you see in the log is an example of when Glimpse wants to know what the current RuntimePolicy is, so that it knows whether or not it should continue to monitor that request. The current RuntimePolicy is set by Glimpse during the BeginRequest phase of that request and the log now indicates it cannot find it, after which Glimpse decides to be concervative and stop monitoring that request instead of ending in a NullReferenceException
Now the cases where we've seen that (check the linked issues inside the issue you mentioned) is when another HttpContext is being created and used to process that request after that Glimpse did is initialization.
So the only advice I can give here, is to check whether the creation of another HttpContext is actually the case for you? You might find some ideas in those linked issues.
In case you find something specific that is not related to the issue mentioned above, then I would suggest you create a new issue on our issue tracker as it is a more appropriate place to discuss potential bugs or missing features
I've been struggling with a problem now for a few hour and I cannot find any answers or anyone with the same problem -
Some menu items are missing on my site www.namhost.com (Drupal 6.22) and when viewing the blog it shows "No blog entries have been created". When I log in as admin everything works fine, so this problem only occurs for anonymous/guest users.
I've changed nothing on the site which may have caused this problem and here comes the really strange part - When viewing a copy of the site locally everything works 100% even for anonymous/guest users.
I've tried:
flushing caches
rebuilding permissions
checked if the "anonymous" user is present in the database
viewing on different browsers
None of these yielded any results.
Because the problem doesn't occur locally I'm starting to believe this could be a problem on the server the site is hosted on (Linux with PHP5.2), but the admins had a look and couldn't find anything.
Any help/insight would be highly appreciated.
================FIXED<<<<<<<-----------------------------
I am not allowed to answer my own question and it was suggested that I edit the question to include my answer so here goes:
Firstly, thanks for all the responses.
I disabled the "ACL" module (http://drupal.org/project/acl) and the problem was solved. It was previously used for our forum which was also disabled a few months back, so it's not needed any more.
I still have no idea why this module caused the site to work locally but not on the server. I will be in contact with the server admins to find out if they changed/updated anything on the server which may have caused this module to cause a malfunction.
Any insight could still be helpful top prevent this from happening again.
Check your Drupal config:
Are you using node_access, content_access, or any other permissions-related addon mods? Disable them and see if the problem persists. If that doesn't work, disable all non-core mods and re-enable them one-at-a-time until you find the offender.
Compare your hosting configs:
If it's not related to Drupal, compare the local and remote server configurations. Do both use the same versions of php, apache, apc, cgi, etc.? A phpinfo(); on both servers should give you the most important details for comparison. Do a similar comparison of the MySQL setup and content. Finally, check for differences in your .htaccess files (if any) between the two locations.
Test another hosting enviornment:
Download a virtual appliance like QuickStart which is already configured to host Drupal sites for development and non-production purposes, and see if the site works correctly in that. If it does, you could do an additional validation by porting to a new host who offers a trial/money-back-guarantee and see if it works correctly there.
If your site works fine elsewhere, give your current host a good thrashing for making you go through all of this to figure out the problem lies on their end.
I am trying to set up an internal nuget feed for my company. I have built the site and deployed it to IIS server. I can install from the site itf I manually add packages to it but I cannot push to it from the command line. When I try to I get prompted for credential (none work) then get an error that says "Cannot access a closed Stream." I have been to NuGet and read everything they propose but none of it works. I am thinking this is a server setting but I have no idea which one. Has anyone encountered this that can share the solution?
Solved this issue by removing WebDAV and adding PUT to the web.config authorization
I just added a comment to the Github issue tracker for a similar (probably identical) problem raised there:
https://github.com/NuGet/NuGetGallery/issues/487
This is probably a result of WebDAV being installed in IIS - it seems to interfere with the settings required for NuGet Gallery. We certainly saw a similar issue with 405 errors, and uninstalling the WebDAV module fixed the problem.
For some magical reason ii6 started to cache pages on the server. Even if I remove the page, it is still displayed. I tried to follow couple suggestions but no luck.
That's what I did so far:
Deleted \WINDOWS\Microsoft.NET\Framework64\v2.0.50727\Temporary ASP.NET Files
Unchecked 'cache ISAPI extensions' in the IIS configuration.
Added 'Cache-Control no-cache' to HTTP headers in properties.
Tried to create the page that clear the cache http://www.dotnet247.com/247reference/msgs/13/67641.aspx
Update: also tried to disable asp cache
IIS ASP Caching
But the files in v2.0.50727\Temporary ASP.NET Files are still created
If anybody has other suggestions, please share.
Thanks.
Please give the delete permission for IIS user on below folder. these files will be deleted automatically by IIS
For 64 bit OS folder path:
\WINDOWS\Microsoft.NET\Framework64\v2.0.50727\Temporary ASP.NET Files
My classic ASP pages WOULD NOT refresh from any browser. Finally, stopping and starting the IIS service (IIS6) fixed the problem.
You, too, can go bonkers, just like me. Simply have IIS start giving out stale pages! A bargain at half the price!
Did you try restarting the IIS server to see if that stops it from displaying? If it doesn't, then it might not be a caching issue.
I believe restarting the server is supposed to clear the cache.
Maybe the problem isn't the IIS, but a web proxy between your browser and your web server caching the page?
Or a wrong DNS settings pointing to another server which holds a copy of that web/page? You could also look on the same IIS if there is another web configured and host headers got mixed up, making you test on the wrong web.
I might just say the obvious here but have you tried recycling the application pool?
Thanks for replies guys.
I figured out that it wasn't the caching issue. I didn't cleared out Bin folder and the compiled version of the page with extension .compiled was seating there all the time. I don't what changed this time, but I followed the same process like 100 times before and copied files on top without clearing Bin.
I should be more accurate with such things.