I have a WCF service hosted on http://localhost:8080, and a web application on http://localhost:82. I have Windows 7 64-bit and IIS 7.5.
The pages in the web app makes AJAX requests to the WCF service using jQuery.
In IE, the service calls perform fine. In Firefox, I get a 405 Method Not Allowed error. The service calls that the web application makes from the ASP.NET code-behind always succeed.
Other developer's builds are having the same problem. I initially thought it had to do with cross-site security restrictions that were introduced in FF 3.5, based on this article: https://developer.mozilla.org/En/HTTP_access_control. However, after adding all the response headers I appeared to need, the problem still occurred.
I've run the aspnet_regiis.exe command, and the WCF ServiceModelReg.exe command as well.
Here is the request that Firefox makes:
OPTIONS http://localhost:8080/ScoutService.svc/Contact_Add HTTP/1.1
Host: localhost:8080
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20100101 Firefox/6.0.2
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip, deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection: keep-alive
Origin: http://localhost:82
Access-Control-Request-Method: POST
Access-Control-Request-Headers: content-type
Pragma: no-cache
Cache-Control: no-cache
Here is the response from the server:
HTTP/1.1 405 Method Not Allowed
Cache-Control: private
Allow: POST
Content-Length: 1565
Content-Type: text/html; charset=UTF-8
Server: Microsoft-IIS/7.5
Set-Cookie: ASP.NET_SessionId=53pqdbqgtj2cfdvtqrikiewu; path=/; HttpOnly
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET
Access-Control-Allow-Origin: http://localhost:82
Access-Control-Allow-Methods: POST, GET, OPTIONS
Access-Control-Max-Age: 17280
Access-Control-Allow-Headers: content-type
Access-Control-Allow-Credentials: true
Date: Thu, 15 Sep 2011 15:55:27 GMT
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>Service</title>
</head>
<body>
<div id="content">
<p class="heading1">Service</p>
<p>Method not allowed.</p>
</div>
</body>
</html>
Any ideas?
Firefox sends an OPTIONS request in addition to a POST or GET.
See http://forums.iis.net/t/1160649.aspx for how to fix it.
Edit
The other thing that is special in your case is that you are using IIS 7.5 which does not allow all verbs by default.
You need to allow the OPTIONS verb
IIS 7.5, Web Service and HTTP 405 error
Related
I have a question about windows authentication with IIS and HttpListner
I have following setup (All installed in same windows 8.1 box. No outside communication). All requests are sent as http://localhost/......
IIS
ASP.Net web application authentication
Anonymous: Disabled
Windows Authentication: Enabled
.Net httpListener
running as a Service run as local System Account. and enabled windows authentication
this.httpListener = new HttpListener();
this.httpListener.AuthenticationSchemes = AuthenticationSchemes.IntegratedWindowsAuthentication;
UWP Application (Windows 8.1)
UWP Application is just like a web browser. It has WebView control to see web contents.
Following capabilities enabled
Enterprise Authentication
Internet (Client)
Location
Private Networks (Client & Server)
Problem
When I navigate from the uwp app to the IIS web app it is asking for the credentials by popping up windows dialog. This is annoying for the user experience perspective because user is logged in with same credencials. But When I access Http Listener it is authenticate correctly and no credentials dialog.
Also I checked the requests through fiddler. Initial request is identical, but with next steps for IIS request, it is continuously asking for NTLM.
HTTP/1.1 401 Unauthorized
Cache-Control: private
Content-Type: text/html; charset=utf-8
Server: Microsoft-IIS/8.5
WWW-Authenticate: Negotiate oYHOMIHLoAMKAQGhDAYKKwYBBAGCNwICC........
WWW-Authenticate: NTLM
X-Powered-By: ASP.NET
Initial Request/Response
IIS
Request
GET http://localhost/webapp_net/ HTTP/1.1
Accept-Encoding: gzip, deflate
Host: localhost
Connection: Keep-Alive
Response
HTTP/1.1 401 Unauthorized
Cache-Control: private
Content-Type: text/html; charset=utf-8
Server: Microsoft-IIS/8.5
WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM
X-Powered-By: ASP.NET
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET,POST
Date: Tue, 20 Nov 2018 21:37:24 GMT
Content-Length: 6016
Proxy-Support: Session-Based-Authentication
HttpListener
Request
GET http://localhost/appman HTTP/1.1
Accept: text/html, application/xhtml+xml, */*
Accept-Language: en-NZ
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; Trident/7.0; WebView/2.0; rv:11.0) like Gecko
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
Host: localhost
Response
HTTP/1.1 401 Unauthorized
Content-Length: 0
Server: Microsoft-HTTPAPI/2.0
WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM
Date: Tue, 20 Nov 2018 21:37:18 GMT
Proxy-Support: Session-Based-Authentication
Does anyone have similar experience or explanation for this ?
I'm stumped, my website was working fine and now on Firefox suddenly the redirects stopped working.
I've tested IE and Chrome and going to /login redirects me to /dashboard however on Firefox the page is blank (no output sent) and no errors are logged. So this is why I'm assuming it to be a browser related issue. It might be due to a firefox update, but not sure how to confirm that.
Here are the headers:
Request Headers
GET /login HTTP/1.1
Host: local.example.com
User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Firefox/24.0 FirePHP/0.7.4
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
DNT: 1
Cookie: __utma=34805930.947644602.1372214584.1380730296.1380733154.30; __utmz=34805930.1378700053.15.2.utmcsr=google|utmccn=(organic)|utmcmd=organic|utmctr=(not%20provided); __utma=214248714.242656582.1377296111.1380047082.1380734348.30; __utmz=214248714.1377296111.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); __qca=P0-705514134-1378344178153; __utmc=34805930; __utmb=34805930.15.10.1380733154; __utmb=214248714.5.10.1380734348; __utmc=214248714; PHPSESSID=lli8i30qkhvohfm9ufkbdvbki0
x-insight: activate
Connection: keep-alive
Response Headers
HTTP/1.1 302 Found
Date: Wed, 02 Oct 2013 17:30:58 GMT
Server: Apache/2.4.3 (Win32) OpenSSL/1.0.1c PHP/5.4.7
X-Powered-By: PHP/5.4.7
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Location: /dashboard
Content-Length: 0
Keep-Alive: timeout=5, max=98
Connection: Keep-Alive
Content-Type: text/html; charset=utf-8
It all looks pretty standard to me, however FF stays stuck on /login Am I missing something?
This behaviour is both on my local windows host and my remote amazon Linux web-server. The body is empty...
How could I go about debugging this?
The Expires header field in the response is really off. Firefox probably does not bother to render stale responses.
Please check the system time in your server. It is possible it is an Amazon problem, but it is also possible that one of the server users set the system time.
You can look into setting up a Network Time Protocol (NTP) client to run regularly (with ntpd), if you don't have that yet.
I would fire up Fiddler to see what bits actually went over the wire. Among other information, Fiddler will show what content type is actually used during the HTTP request / response.
This could be related to the fact that there is no extension. Firefox could be having trouble determining if this is a document or folder. Try firebug and see what URL Firefox tries to request after the redirect.
I try to save a backbone model with model.save(), I gave the urlRoot, and I'm waiting for a POST call. I have a REST service on another subdomain which is waiting for the request.
I got these request headers by the model.save().
OPTIONS /user HTTP/1.1
Host: rest.secret.loc
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:20.0) Gecko/20100101 Firefox/20.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Origin: http://members.secret.loc
Access-Control-Request-Method: POST
Access-Control-Request-Headers: content-type
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache
Sy mentioned that this is a preflight request, so I should respond with the following headers:
HTTP/1.1 200 OK
Cache-Control: max-age=0, no-cache, no-store, must-revalidate
Pragma: no-cache
Content-Type: text/html
Expires: Wed, 11 Jan 1984 05:00:00 GMT
Server: Microsoft-IIS/7.5
X-Powered-By: PHP/5.3.8, ASP.NET
access-control-allow-origin: http://members.secret.loc
Access-Control-Allow-Methods: POST, GET, PUT, DELETE, OPTIONS
Date: Fri, 17 May 2013 01:18:21 GMT
Content-Length: 0
I tried out, but this is not working, the browser does not send another request to the server :S :S :S :S :S
How to fix it?
Is this a backbone bug?
I tried out with Chrome, and in chrome console appears what in firebug not:
The content-type header is not allowed. So I modified the web.config file:
<add name="Access-Control-Allow-Headers" value="Content-Type" />
This fixed the problem.
Btw it still sends the preflight, so I put this code on server side:
if ($_SERVER['REQUEST_METHOD'] == 'OPTIONS')
exit;
So it won't mess up everything...
We are trying to access Google Maps over HTTPS.
We modified the script on the JSP to
script src="https://maps.googleapis.com/maps/api/js?client=<xxxx>&sensor=false" type="text/javascript"
This seems to work properly in Chrome and IE8. But in Firefox(V 19.0.2 and 11), there are some issues.
Specifically, We are getting
TypeError: google.maps.InfoWindow is not a constructor
in the Firefox console which I think means that the Google APIs are not getting accessed properly.
Any suggestions/solutions for this issue?
More:
We are getting a 407 response from googlemaps apis.
Specifically, using Fiddler the Request looks like:
CONNECT maps.googleapis.com:443 HTTP/1.1
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:19.0) Gecko/20100101 Firefox/19.0
Proxy-Connection: keep-alive
Connection: keep-alive
Host: maps.googleapis.com
and the Response looks like:
HTTP/1.1 407 Proxy Authorization Required
Date: Mon, 22 Apr 2013 04:46:47 GMT
Proxy-Connection: keep-alive
Via: 1.1 XXXXX
Cache-Control: no-store
Content-Type: text/html
Content-Language: en
Proxy-Authenticate: NTLM
Proxy-Authenticate: Basic realm="Websense Content Gateway"
Content-Length: 322
Proxy-Support: Session-Based-Authentication
<HEAD><TITLE>Proxy Authorization Required</TITLE></HEAD>
<BODY BGCOLOR="white" FGCOLOR="black"><H1>Proxy Authorization Required</H1><HR>
<FONT FACE="Helvetica,Arial"><B>
Description: Authorization is required for access to this proxy</B></FONT>
<HR>
<!-- default "Proxy Authorization Required" response (407) -->
</BODY>
Damn.. Its an issue with my company's internet proxy!! I had to add an exception to all the URLs used by my application(including google map apis) and it works fine.
Add all urls of google map api over https in Location input bar for certificate exceptions.
for example:
https://maps.googleapis.com
https://maps.gstatic.com
'Get Certificate' then 'Confirm Security Exception'
Tools > Advanced > Certificates > View Certificates > 'Servers' Tab > 'Add Exception...'
Within Firefox 9 & 10 using Firebug and Live Headers,
I am seeing the websocket request/response pairs being sent across domains but with the wrong Cookie: contents.
Give two urls -
Base web page - http://www.mysite.test/mywebapp
Websocket url - http://stompeserver.mysite.test/stomp
The browser seems to be sending the cookies for the base page hostname rather any cookies associated with the secondary hostname. i.e. the JSESSIONID cookie loaded with the base web page is being echoed to the external connection.
Is this a bug or expected behavior? Nowhere have I seen how to websockets are suppose react to cookies.
IMO, this can be a really serious security violation by exposing a site's cookies to an external websocket service.
Updated to firefox 10 and still see an issue.
Below is a slightly clarified Live Headers trace of two back to back connections
The JSESSIONID and CLIENT_LOCALE cookies are copied to from 9443 the app server to 61623 the mq server.
----------------------------------------------------------
https://myapp.com:9443/server/themes/standard/public/gwt/xxstandard/images/logout-icon.png
GET https://myapp.com:9443/server/themes/standard/public/gwt/xxstandard/images/logout-icon.png HTTP/1.1
Host: myapp.com:9443
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.1) Gecko/20100101 Firefox/10.0.1
Accept: image/png,image/*;q=0.8,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
Referer: https://myapp.com:9443/server/example.htm?gwt.codesvr=127.0.0.1:9997&log_level=INFO
Cookie: JSESSIONID=0000wCOpgfIsSNOz2lL22O5LOiI:-1; CLIENT_LOCALE=en_US;
Pragma: no-cache
Cache-Control: no-cache
HTTP/1.1 200 OK
Date: Thu, 16 Feb 2012 19:02:55 GMT
Content-Type: text/plain
Last-Modified: Wed, 29 Jun 2011 20:44:11 GMT
Content-Length: 669
Content-Language: en-US
Server: WebSphere Application Server/7.0
----------------------------------------------------------
http://myapp.com:61623/stomp
GET http://myapp.com:61623/stomp HTTP/1.1
Host: myapp.com:61623
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.1) Gecko/20100101 Firefox/10.0.1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip, deflate
Proxy-Connection: keep-alive
Sec-WebSocket-Version: 8
Sec-WebSocket-Origin: https://myapp.com:9443
Sec-WebSocket-Key: FToA/HGiVQN3CbGOgNffMA==
Cookie: JSESSIONID=0000wCOpgfIsSNOz2lL22O5LOiI:-1; CLIENT_LOCALE=en_US;
Pragma: no-cache
Cache-Control: no-cache
Upgrade: websocket
Connection: Upgrade
HTTP/1.1 101 Switching Protocols
Upgrade: WebSocket
Connection: Upgrade
Sec-WebSocket-Accept: 5lqrLU4mbPiEasSn4gqOlqWvGgw=
----------------------------------------------------------
Same-origin policy and CORS doesn't apply to WebSockets.
With WS, a "origin" HTTP header is sent in the initial WS opening handshake, and for browsers, this origin header MUST contain hostname of the server that originally served the HTML/JS that opens the WS.
The WS server is then free to accept/deny.
With non-browser WS clients, the origin header may or may not be present, and may contain anything.
Cookies: it's not specified by the WS spec. See Patrick's response (Firefox WS developer) here
http://www.ietf.org/mail-archive/web/hybi/current/msg08017.html