Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I have windows client application and windows service hosting a web service over HTTPS (on behind it uses standard http.sys). Everything is ok except the situation where user makes a mistake and uses HTTP with HTTPS port for accessing the service. For example service is exposed on: https://somehost:9000 but user incorrectly sets http://somehost:9000.

Normally if the endpoint is not available the client receives 404 Not found but in this case the endpoint is available but the host expects SSL\TLS handshake first. When the client calls the service with pure HTTP it hangs and client waits for timeouts. Moreover I found that this is some global behavior because web services exposed on IIS over HTTPS called through browser with HTTP behaves in the exactly same way. The timeout is always 130s. Keep-alive for connections on IIS is configured to 120s so it doesn't look correlated.

What kind of timeout is used in this case? Is it possible to change it (this question is little bit abstract because I yet don't know what I want to change)?

share|improve this question
    
I've also run into a 130 second timeout when dealing with WCF streaming using the basicHttp binding. I found that if I have a delay of longer than 130 between providing bytes to the server from my stream on the client then I'll get a timeout related exception on the client. I'm assuming the server is killing the inactive connection after 130 seconds. Not sure what is determining this timeout value though yet. –  jpierson Jan 10 '13 at 17:16

1 Answer 1

I think you can use the URL rewrite module, which does a kind of transparent redirect to the correct protocol; here are some details

install and enable the URL rewrite and configure your ISS virtual site to not require-ssl, so that it can handle the HTTP request, and send a http-redirect back to https:// like so

<rule name="HTTP to HTTPS redirect" stopProcessing="true">
  <match url="(.*)" />
    <conditions>
      <add input="{HTTPS}" pattern="off" ignoreCase="true" />
    </conditions>
  <action type="Redirect" redirectType="Found" url="https://{HTTP_HOST}/{R:1}" />
</rule>

This strategy is better than making possibly breaking changes to system-wide TCP parameters.


Alternative is to set the appropriate timeout values on http.sys component in your application. Some default values and parameters are mentioned in this doc here;

http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/31a2f39c-4d59-4cba-905c-60e7af657e49.mspx?mfr=true

share|improve this answer
1  
I see two problems in that solution. It expects that user arrives at HTTP port and it redirects him to HTTPS port (80->443). In my case I use non default port and user arrives always on the correct one but with wrong protocol. I don't think I can expose both HTTP and HTTPS on the same port. The second problem is that modules are feature of IIS - I used IIS only to reproduce the issue found in self hosted scenario. –  Ladislav Mrnka May 25 '12 at 14:44
    
i think it would match on both ports, but I don't have IIS available to test right now, and given the details of your second point it is moot to test... :-( –  Tom H May 25 '12 at 14:49
    
can you give details on "self hosted" scenario? –  Tom H May 25 '12 at 14:50
    
I suspect the principle would be similar what ever the server application was, your server would have to inspect the request and redirect HTTP requests to https:// and that would have to be configured in your app. –  Tom H May 25 '12 at 15:07
    
Self hosted scenario uses low level HTTP API wrapped by .NET. The same low level HTTP API is used by IIS. –  Ladislav Mrnka May 25 '12 at 15:14

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.