We are developing an application using Adobe Air from the client gui with a mix of WCF and REST on the backend. One of the requirements of this application is that it must work offline. So, when the user clicks save, the application stores it in a local sqlite database. Every 15 seconds, the application checks if it is online, and if so, sends any pending requests out. Then if the call succeeds it updates the local database so it won't try to send that case out again.
For this particular operation - OpenMedicalCase, the app sends out the request and can't decode the response. I am verifying that the WCF side of things is working correctly. The response message is well formed. The network monitor in flashbuilder says I am receiving 100 Continue:
POST /services/medicalcase.svc HTTP/1.1
Referer: app:/AWC_MRDS.swf
Accept: text/xml, application/xml, application/xhtml+xml, text/html;q=0.9, text/plain;q=0.8, text/css, image/png, image/jpeg, image/gif;q=0.8, application/x-shockwave-flash, video/mp4;q=0.9, flv-application/octet-stream;q=0.8, video/x-flv;q=0.7, audio/mp4, application/futuresplash, /;q=0.5
x-flash-version: 10,1,53,64
Content-Type: text/xml; charset=utf-8
SOAPAction: "http://tempuri.org/IMedicalCaseService/OpenMedicalCase"
Content-Length: 8534
User-Agent: Mozilla/5.0 (Windows; U; en-US) AppleWebKit/531.9 (KHTML, like Gecko) AdobeAIR/2.0.2
Host: localhost:11934
Cookie: RememberMe=1147670691^1#3435272784175716681
HTTP/1.1 100 Continue
Server: ASP.NET Development Server/10.0.0.0
Date: Thu, 23 Dec 2010 21:23:49 GMT
Content-Length: 0
Calls to other operations at the same endpoint are returning 200 OK like expected. So what ends up happening is that flex thinks the call did not succeed and sends it over and over again. AFAIK flex is not sending Expect: 100-Continue in the headers either.
Update: I attached debuggers to the wcf service AND the gui, setting a breakpoint right before the server sends a response. Flex receives 100 Continue before the service code returns anything. Please note that I am only testing this using the ASP.NET development server. Is there some property or configuration option I need to change on the flex side? WCF?
Related
I'm working on a prototype project connecting a self-hosted SignalR server running on Mono with C# clients (for testing) and Unity clients (representing the actual use-case scenario). The Unity client is using BestHTTP Pro as its SignalR library.
As the WebSocket transport method is not supported on Mono, I'm focusing on server-sent events, and observing very odd behavior there. Communication between server and C# clients is working just fine out of the box. With the Unity client though, the (supposedly) persistent connection is closed immediately after the initial response to the /signalr/connect request. No errors are reported anywhere; the response code is 200 in both cases.
Further investigation with Fiddler reveals that the Unity client is sending a Connection: Keep-Alive header that the C# client doesn't send, to which the server responds with a Connection: close header and, well, closing the connection (in other words, exactly the opposite of what the client asks it to do).
Manually removing the keep-alive request header actually makes everything work with the Unity client. Since this feels more like an odd workaround than a correct solution, my question is: Is this strange server-side behavior a bug in the SignalR libraries? Or could Mono be to blame here (I suspect this might be the case)? How can I dig deeper into this, and ideally make the SSE transport work without client-side hacks?
Library versions used:
Microsoft ASP.NET SignalR 2.2.1
BestHTTP Pro 1.9.17
For reference, here are the full request/response headers; Unity/BestHTTP client:
GET /signalr/connect?tid=1&_=XXX&transport=serverSentEvents&clientProtocol=1.5&connectionToken=XXX&connectionData=XXX HTTP/1.1
Accept: text/event-stream
Cache-Control: no-cache
Accept-Encoding: identity
Host: XXX
Connection: Keep-Alive
Connection: Keep-Alive, TE
TE: identity
User-Agent: BestHTTP
HTTP/1.1 200 OK
X-Content-Type-Options: nosniff
Content-Type: text/event-stream
Server: Mono-HTTPAPI/1.0
Date: Wed, 08 Mar 2017 10:34:05 GMT
Connection: close
Content-Length: 73
C# client:
GET /signalr/connect?clientProtocol=1.4&transport=serverSentEvents&connectionData=XXX&connectionToken=XXX HTTP/1.1
User-Agent: SignalR.Client.NET45/2.2.1.0 (Microsoft Windows NT 6.2.9200.0)
Accept: text/event-stream
Host: XXX
HTTP/1.1 200 OK
X-Content-Type-Options: nosniff
Content-Type: text/event-stream
Server: Mono-HTTPAPI/1.0
Date: Wed, 08 Mar 2017 13:11:16 GMT
Transfer-Encoding: chunked
Keep-Alive: timeout=15,max=99
BestHTTP developer here.
First of all, the plugin can use WebSocket as a SignalR transport on every supported platform. While the mono framework that Unity uses has no WebSocket implementation, the plugin uses its own.
The Server-Sent Events protocol has no direct indication what should be done for a case like this, but modified the plugin to work the same way as other clients. You can wait for the next release on the Asset Store, or you can contact me for an updated package.
I have hosted ASP NET 4.5 application in Windows Server 2012 R2 (IIS Version 8.5.9600.16384). But once in a while I am getting an error like Bad Request - Invalid Verb HTTP Error 400. The request verb is invalid while going from one page to another. There is no special sequence or specific page where I am getting this error.
httperr log file shows me an error like
2015-01-21 04:48:18 MyIP 55452 ServerIP 80 - - - 400 - Verb -
2015-01-21 04:48:20 MYIP 55454 SerevrIP 80 - - - 400 - Verb -
I checked this post http://support.microsoft.com/kb/828726 but here it is applicable for Microsoft Internet Information Services (IIS) 6.0. Can I do this hotfix for iis 8.5 as well. I have searched about this issue over the internet but could not get substantial information. So, can anyone help me resolve this issue.
Using Fiddler I got the Raw Data of the request as
POST http://example.com/Project.aspx?prj=5566 HTTP/1.1
Host: example.com
Connection: keep-alive
Content-Length: 30634
Cache-Control: max-age=0
Authorization: Negotiate
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Origin: http://example.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.99 Safari/537.36
Content-Type: application/x-www-form-urlencoded
Referer: http://example.com/Project.aspx?prj=5566
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.8
Cookie: ASP.NET_SessionId=4oymd5odmcaluiuzc24tbx22; _gat=1; _ga=GA1.2.1888408676.1418017144
The Request Filtering Setting of Windows Server 2012 R2 is
Any help would be appreciated.
Try adding
EnableViewState="false"
to your aspx page. It looks like Chrome adds the viewstate where IIS expects the request verb.
You might have some luck with this: Fix HTTP.sys
400 Status Code
400 status means “Bad Request”. So this is not a server-side issue. There is something wrong with the request. Is not well-formed before reaching to IIS
If the substatus code was something other than 0, it would be easier to troubleshoot. For example, If it was 1, it would mean “Invalid Destination Header”. If it was 2, that would mean “Invalid Depth Header”. Here is the full list of status codes.
If you see value 64 in sc-win32-status, it means there is a network-related issue. It refers to “The specified network name is no longer available”. After sending the response, IIS waits for ACK package from the client. If the client resets the connection instead of sending this package, IIS logs 64 code since it’s not a graceful connection close.
Check HTTPERR log for the same timestamp. In my case, I saw Timer_EntityBody error which means “The connection expired before the request entity body arrived”.
Recommendations
Check if there are software like antivirus or network endpoint
protection in the server. Uninstall them and monitor the system for a
while to see if the issue occurs again (Note: disabling them
sometimes doesn't mean they don't run in the background anymore.
Uninstalling is the ultimate way of eliminating them from the
troubleshooting process)
Work with the third-party product support to
see if there is anything blocking the requests to be fully sent.
Application might be initiating the connection but not completing it
Check with your Networking team to analyze the network between the
web server and client. Ideally, a network trace would be very helpful
Source: Status Code 400 with 64 in sc-win32-status column
I create a webdav connection with the Windows 8 built-in WebDAV client (Microsoft-WebDAV-MiniRedir).
I have only a read permission for the files and try to delete one.
I can open by right-click the context menu and delete it, although my WebDAV server returns 401 Unauthorized. The file disappears in the explorer as if it has been deleted.
If I close the explorer window and open it again, the file is back again, what is ok.
Why the deletion is not refused and why I doesn't get from the WebDAV client an error message like "401 unauthorized access"?
Here are the request and response.
Request:
DELETE https://xxx.yyy.zz/webdav/mysharedfolder/file1.txt HTTP/1.1
Connection: Keep-Alive
User-Agent: Microsoft-WebDAV-MiniRedir/6.3.9600
translate: f
Host: xxx.yyy.zz
Authorization: Basic dlk7uXNvcmt1QHdlYi5kZTpRd2VyMTIzNA==
Cookie: JSESSIONID=A7497F42472ECC676E44A90E3C5D5E7
Response:
HTTP/1.1 401 Unauthorized
Date: Thu, 13 Nov 2014 23:21:43 GMT
Server: Apache-Coyote/1.1
WWW-Authenticate: Basic realm="https://xxx.yyy.zz/webdav/mysharedfolder/file1.txt"
Content-Length: 0
Connection: close
Content-Type: text/plain; charset=UTF-8
A redirect on an OPTIONS request (or in any webdav request actually) is suspicious, and I wouldnt assume windows will correctly handle that, so that might be something to look at. But i also vaguely remember encountering something similar with Win7 years ago. A workaround might be to return a different 4xx error code for the mini-redirector agent.
If my browser uses cache (local cache), does it GUARANTEE that each HTTP request it sends contains "IF MODIFIED SINCE" header line?
If not, how do I define that it will ? and what if I define a proxy server to the browser ? will it add it automatically then?
thanks in advance
I was just working on this with my RESTful web service and ran a few tests for a particular resource. First of all I was trying to control the browser cache from my web server by setting the following HTTP headers on the HTTP response for the resource:
Cache-Control: must-revalidate, max-age=30
Last-Modified: Mon May 19 11:21:05 GMT 2014
Expires: Mon May 19 11:51:05 GMT 2014
Then from my web UI I have a timer that periodically (every 5 seconds) does a GET on the resource that I've said is cacheable. Since the resource in the browser cache has not yet expired the GET request for the resource is served from the browser cache, however, once the "max-age" has expired the next GET request goes to the server and the browser adds the "If-Modified-Since" header with the "Last-Modified" date as the value like this:
[GET] - /cms_cm_web/api/notification
referer: http://localhost:8080/cms_ui/#/
accept: application/json, text/plain, */*
accept-language: en-us
ua-cpu: AMD64
accept-encoding: gzip, deflate
user-agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Win64; x64; Trident/5.0)
host: localhost:8080
if-modified-since: Mon, May 19 11:21:05 GMT 2014
connection: Keep-Alive
This came from IE9 browser. I get the same from latest Firefox and Chrome browsers as well.
From here the server can look for the "If-Modified-Since" header and if it determines the resource has not been modified then it returns a 304 Not Modified response, otherwise, it returns the resource representation with a 200 OK response.
so according to the HTTP specification you can control caching using "Expires" and/or "Cache-Control" headers together with a "Last-Modified" header. This will cause the browser cache to perform what's called a "conditional GET" request as it includes the "If-Modified-Since" header.
I experience strange behavior when doing HTTP requests through sockets, here the request:
POST https://example.com:443/service/XMLSelect HTTP/1.1
Content-Length: 10926
Host: example.com
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 1.0.3705)
Authorization: Basic XXX
SOAPAction: http://example.com/SubmitXml
Later on there goes body of my request with given content length.
After that I receive something like:
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Content-Type: text/xml;charset=utf-8
Transfer-Encoding: chunked
Date: Tue, 30 Mar 2010 06:13:52 GMT
So everything seem to be fine here. I read all contents from network stream and successfully receive response. But my socket which I'm doing polling on switches it's modes like that:
write ( i write headers and request here )
read ( after headers sent i begin to receive response )
write ( STRANGE BEHAVIOUR HERE. WHY? here i send nothing really )
read ( here it switches to read back again )
last two steps can repeat several times. So I want to ask what leads for socket's mode change? And in this case it's not a big problem, but when I use gzip compression in my request ( no idea how it's related ) and ask server to send gzipped response to me like this:
POST https://example.com:443/service/XMLSelect HTTP/1.1
Content-Length: 1076
Accept-Encoding: gzip
Content-Encoding: gzip
Host: example.com
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 1.0.3705)
Authorization: Basic XXX
SOAPAction: http://example.com/SubmitXml
I receive response like that:
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Content-Encoding: gzip
Content-Type: text/xml;charset=utf-8
Transfer-Encoding: chunked
Date: Tue, 30 Mar 2010 07:26:33 GMT
2000
�
I receive a chunk size and GZIP header, it's all okay. And here's what is happening with my poor little socket meanwhile:
write ( i write headers and request here )
read ( after headers sent i begin to receive response )
write ( STRANGE BEHAVIOUR HERE. And it finally sits here forever waiting for me to send something! But if i refer to HTTP I don't have to send anything more! )
What can it be related to? What it wants me to send? Is it remote web server's problem or do I miss something?
PS All actual service references and login/passwords replaced with fake ones :)
A socket becomes writable whenever there's space in the socket send buffer. The OS can't really know if your application has more data to send, but knows about its internal structures, like socket buffers. You have to explicitly add/remove the socket to the write fd_set for select(2) (enable/disable EPOLLOUT event for epoll(4)). This is usually handled with a state machine, like in libevent. Also polling works best with non-blocking sockets.
Hope this helps.