Reputation: 2196
(other than secure sockets and the underlying transport protocol, I mean)
I'm trying to implement the most basic HTTP server in C# (specifically, I'm trying to get my program to create a local socket listening on http://localhost:nnnn where nnnn is a custom port number, that responds as if it were a secure web server).
I've got the basic communications code working, accepting connections, receiving requests and responding to GET. I know this works in principle because if I point my brower to my listening socket via standard HTTP, it all works and it happily displays the web page I return.
But if I try and connect using HTTPS (I use a different port number), it connects, accepts and even gets the GET request OK - but despite me returning a response, the browser seems to hang, as if it is waiting for something else - and yet I receive nothing else as far as I know (I'm still listening for connections, in case it decided to make other connections).
My response is this:
HTTP/1.1 200 OK
Host: localhost:4301
Date: <assume date is correctly formatted>
Content-Type: text/html; charset=us-ascii
Content-Length: 52
Connection: Keep-Alive
<html><head></head><body>Hello, World!</body></html>
As I said, this works fine for standard HTTP - the browser accepts it. I tried to include the header items I thought it might insist on (I also tried Connection: Close and forcibly terminating the connection - in that case the browser shows a connection problem. The GET it sent specified Keep-Alive, so I returned to that).
Is there something I'm missing to get the browser to accept the response for HTTPS like it did for HTTP?
If it helps, the GET request I receive for the HTTPS case is:
GET /test.html?param1=Test HTTP/1.1
Accept: text/html, application/xhtml+xml, */*
Accept-Language: en-US
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)
Accept-Encoding: gzip, deflate
Host: localhost:4301
Connection: Keep-Alive
Also, I'm using a self-signed cert created using MAKECERT - I have to accept warnings and force the browser to continue to the page because of this, but the point is, it does eventually send the GET request.
Upvotes: 1
Views: 485
Reputation: 2196
Ugh... embarrassing. Turns out I was sending my perfectly-formed response... on the wrong stream. I was sending it back on the standard NetworkStream object instead of the SslStream one. Funny how things work better when you code it properly {:v(
Upvotes: 1