We just deployed a perfectly working Umbraco site to a staging environment that uses a self-signed SSL cert and when we attempt to Save/Publish anything in BackOffice, we get the following error:
)]}',
{"Message":"The requested resource does not support http method 'GET'."}
We're using the URLRewrite module for IIS with a specialized port number just to redirect any HTTP requests to HTTPS. I've disabled that rule to see if that was the culprit, but doesn't make a difference. The umbracoUseSSL is set to true in web.config.
Well, I've looked and looked and pretty much stuck. It appears even attempting to login to BackOffice results in the same error being thrown. Thing is, wouldn't saving/publishing content or trying to log in issue a POST? The error message is telling me that the method doesn't support GET verb. The only main things that are different between between our dev enviroment and this staging environment is that in Dev, we're using Http w/ IISExpress, while staging environment is HTTPS w/ IIS 8.5.
So, I've completely removed any sort of SSL/HTTPS configuration from the server, but still get the same error so it obviously has nothing to do with the website running under SSL.
I can't login or save any content or templates due to the same 405 Method Not Allowed error. In F12ing the web pages as I attempt to save anything, it appears that a POST is being made, but then a GET is attempted to the same URL again. I'm not sure what is doing this?? It's like something is performing a 301 redirect?? I've completely removed URL Rewrite Module from IIS and removed all rewrite config from web.config. Still makes no diff.
Below is the IIS log file for a few of the last requests I've made. The website comes up just fine, but when I try to go to BackOffice, and have to POST anything (like logging in) that's when I see these 405 and 404 errors. (I've changed IP addresses and urls for sake of not exposing that info)
2016-07-28 19:22:59 10.0.0.5 GET /dependencyhandler.axd s=[removed all this encrypted stuff for ease of reading]&t=Javascript&cdv=1753334890 80 - 57.161.21.20 Mozilla/5.0+(Windows+NT+10.0;+WOW64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/51.0.2704.106+Safari/537.36 http://customazuredc1.cloudapp.net/umbraco 304 0 0 109
I should point out that I've targeted .NET Framework 4.6.1 in the project and installed it on the server as well. Not sure if there's some version mismatching, but don't know how to determine if there is.
Looking at the log something is doing a 301 redirect, usually used for redirecting old pages to new. I woild base my investigations on ensuring there are no rewrite rules in your infrastucture that could do this. You said it was ok in development so this questionay not apply but are you using any of the urlrewrite packages
I agree with Ian, it looks like you have a lowercase re-write rule going on.
I've seen the same issue with a re-write rule that appends an / to end of URLS.
If you have these re-writes you need to put an exclusion for anything that has /umbraco/ in the URL else they will fail.
/surface/ should also be excluded.
Finally, found the issue..... as I mentioned, I did have the UrlRewrite Module installed in IIS at one point with a 301 Redirect occurring for these rewrites. Although I removed that, the 301 was being cached! Everything working now. I'll need to include the redirect module back in now and exclude any umbraco backoffice urls from getting rewritten.
405 Method Not Allowed Error on Save/Publish
Hi there,
We just deployed a perfectly working Umbraco site to a staging environment that uses a self-signed SSL cert and when we attempt to Save/Publish anything in BackOffice, we get the following error:
If I navigate directly to that url, I get:
We're using the URLRewrite module for IIS with a specialized port number just to redirect any HTTP requests to HTTPS. I've disabled that rule to see if that was the culprit, but doesn't make a difference. The umbracoUseSSL is set to true in web.config.
Anyone experienced this before?
Well, I've looked and looked and pretty much stuck. It appears even attempting to login to BackOffice results in the same error being thrown. Thing is, wouldn't saving/publishing content or trying to log in issue a POST? The error message is telling me that the method doesn't support GET verb. The only main things that are different between between our dev enviroment and this staging environment is that in Dev, we're using Http w/ IISExpress, while staging environment is HTTPS w/ IIS 8.5.
Help anyone??
So, I've completely removed any sort of SSL/HTTPS configuration from the server, but still get the same error so it obviously has nothing to do with the website running under SSL.
I can't login or save any content or templates due to the same 405 Method Not Allowed error. In F12ing the web pages as I attempt to save anything, it appears that a POST is being made, but then a GET is attempted to the same URL again. I'm not sure what is doing this?? It's like something is performing a 301 redirect?? I've completely removed URL Rewrite Module from IIS and removed all rewrite config from web.config. Still makes no diff.
Below is the IIS log file for a few of the last requests I've made. The website comes up just fine, but when I try to go to BackOffice, and have to POST anything (like logging in) that's when I see these 405 and 404 errors. (I've changed IP addresses and urls for sake of not exposing that info)
2016-07-28 19:22:59 10.0.0.5 GET /dependencyhandler.axd s=[removed all this encrypted stuff for ease of reading]&t=Javascript&cdv=1753334890 80 - 57.161.21.20 Mozilla/5.0+(Windows+NT+10.0;+WOW64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/51.0.2704.106+Safari/537.36 http://customazuredc1.cloudapp.net/umbraco 304 0 0 109
2016-07-28 19:23:01 10.0.0.5 GET /umbraco/lib/moment/moment-with-locales.js umb__rnd=7.4.3.1753334890 80 - 57.161.21.20 Mozilla/5.0+(Windows+NT+10.0;+WOW64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/51.0.2704.106+Safari/537.36 http://customazuredc1.cloudapp.net/umbraco 304 0 0 109
2016-07-28 19:23:01 10.0.0.5 GET /umbraco/views/components/notifications/umb-notifications.html umb__rnd=7.4.3.1753334890 80 - 57.161.21.20 Mozilla/5.0+(Windows+NT+10.0;+WOW64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/51.0.2704.106+Safari/537.36 http://customazuredc1.cloudapp.net/umbraco 304 0 0 109
2016-07-28 19:23:01 10.0.0.5 GET /umbraco/views/components/application/umb-navigation.html umb__rnd=7.4.3.1753334890 80 - 57.161.21.20 Mozilla/5.0+(Windows+NT+10.0;+WOW64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/51.0.2704.106+Safari/537.36 http://customazuredc1.cloudapp.net/umbraco 304 0 0 109
2016-07-28 19:23:01 10.0.0.5 GET /umbraco/views/components/overlays/umb-overlay.html umb__rnd=7.4.3.1753334890 80 - 57.161.21.20 Mozilla/5.0+(Windows+NT+10.0;+WOW64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/51.0.2704.106+Safari/537.36 http://customazuredc1.cloudapp.net/umbraco 304 0 0 109
2016-07-28 19:23:01 10.0.0.5 GET /umbraco/views/common/login.html umb__rnd=7.4.3.1753334890 80 - 57.161.21.20 Mozilla/5.0+(Windows+NT+10.0;+WOW64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/51.0.2704.106+Safari/537.36 http://customazuredc1.cloudapp.net/umbraco 304 0 0 109
2016-07-28 19:23:01 10.0.0.5 GET /umbraco/localizedtext - 80 - 57.161.21.20 Mozilla/5.0+(Windows+NT+10.0;+WOW64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/51.0.2704.106+Safari/537.36 http://customazuredc1.cloudapp.net/umbraco 200 0 0 312
2016-07-28 19:23:15 10.0.0.5 POST /umbraco/backoffice/UmbracoApi/Authentication/PostLogin - 80 - 57.161.21.20 Mozilla/5.0+(Windows+NT+10.0;+WOW64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/51.0.2704.106+Safari/537.36 http://customazuredc1.cloudapp.net/umbraco 301 0 0 62
2016-07-28 19:23:15 10.0.0.5 GET /umbraco/backoffice/umbracoapi/authentication/postlogin - 80 - 57.161.21.20 Mozilla/5.0+(Windows+NT+10.0;+WOW64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/51.0.2704.106+Safari/537.36 http://customazuredc1.cloudapp.net/umbraco 405 0 0 124
2016-07-28 19:23:31 10.0.0.5 POST /umbraco/RestServices/ScheduledPublish/Index - 80 - 13.68.91.101 - - 301 0 0 0 2016-07-28 19:23:31 10.0.0.5 GET /umbraco/restservices/scheduledpublish/index - 80 - 13.68.91.101 - - 404 0 0 31 2016-07-28 19:24:31 10.0.0.5 POST /umbraco/RestServices/ScheduledPublish/Index - 80 - 13.68.91.101 - - 301 0 0 0 2016-07-28 19:24:31 10.0.0.5 GET /umbraco/restservices/scheduledpublish/index - 80 - 13.68.91.101 - - 404 0 0 15 2016-07-28 19:25:31 10.0.0.5 POST /umbraco/RestServices/ScheduledPublish/Index - 80 - 13.68.91.101 - - 301 0 0 0 2016-07-28 19:25:31 10.0.0.5 GET /umbraco/restservices/scheduledpublish/index - 80 - 13.68.91.101 - - 404 0 0 15 2016-07-28 19:26:31 10.0.0.5 POST /umbraco/RestServices/ScheduledPublish/Index - 80 - 13.68.91.101 - - 301 0 0 0 2016-07-28 19:26:31 10.0.0.5 GET /umbraco/restservices/scheduledpublish/index - 80 - 13.68.91.101 - - 404 0 0 46
I should point out that I've targeted .NET Framework 4.6.1 in the project and installed it on the server as well. Not sure if there's some version mismatching, but don't know how to determine if there is.
Looking at the log something is doing a 301 redirect, usually used for redirecting old pages to new. I woild base my investigations on ensuring there are no rewrite rules in your infrastucture that could do this. You said it was ok in development so this questionay not apply but are you using any of the urlrewrite packages
I agree with Ian, it looks like you have a lowercase re-write rule going on. I've seen the same issue with a re-write rule that appends an / to end of URLS.
If you have these re-writes you need to put an exclusion for anything that has /umbraco/ in the URL else they will fail. /surface/ should also be excluded.
I did have the Url Rewrite module installed in IIS on that server and thought that may be the culprit, but I've since uninstalled it, removed the
Finally, found the issue..... as I mentioned, I did have the UrlRewrite Module installed in IIS at one point with a 301 Redirect occurring for these rewrites. Although I removed that, the 301 was being cached! Everything working now. I'll need to include the redirect module back in now and exclude any umbraco backoffice urls from getting rewritten.
Thanks for the help guys!
is working on a reply...