But there are some other aspects, even when you have good, single, consistent standards the challenge can be implementations.
My fun today revolved around TLS and https.
So, the way it is meant to work, is when we close a connection, we send a TLS level close alert, and the other end sends us one, and then we close the TCP connection underneath. This is pretty simple and works for almost all connections...
Except...
Testing Edge on MS Windows 10. Some of the pages on the FireBrick are dynamic and so work on a Connection: close basis. This means, instead of a Content-Length at the start, the data in the page is sent until the connection is closed.
For http this is simple, we close the TCP at the end, job done.
For https it should be simple, we do a TLS close message, we should get one back and then close TCP, but no... We get no reply to the TLS level close, and TCP stays open. The web browser shows the page not completely loaded, and so the onLoad javascript does not run and all sorts of other nasty side effects, WTF?!
The fix is not too hard, a half close on tx side to send a FIN after the TLS level close, allowing far end to send a TLS close back or just close at TCP level (which is what Edge does).
But it has taken three engineers several hours of work today to diagnose and work around this. Arrrg!
What is also fun is we find Edge appears to do a sort of speculative connection. If it does not have a clean keep-alive session it makes a new connection when it has nothing to say, just in case. This was causing exception handling our side (as we expect a prompt request when we get a connection) which also closed TLS uncleanly and impacted session resumption. We have had to make changes for that too.
The good news, after all that, is we now work with Edge (we already worked with pretty much everything else), so should finally have the new https code release this evening at some point. Watch this space.
I have to say, and this is all down to Cliff, that the https is really surprisingly snappy and responsive. One customer said he could swear it was faster than http, which makes no sense. I am quite impressed.
There is someone who uses Edge? Never realised that.
ReplyDeleteMicrosoft says that Edge is the fastest browser ever. Apparently it is 10% faster than Chrome.
DeleteHuh! I use it all the time, no proble
ReplyDeleteWhat - Microsoft not bothering to implement things properly to a standard? That must be a first.
ReplyDeleteHold on a minute. What about Silverlight? That Silverlight thing was worse than Flash but Microsoft still rolled it out then discontinued it.
DeleteI had a funny bug with Safari and haproxy TLS termination recently.
ReplyDeletehttps://discourse.haproxy.org/t/server-dropped-connection-with-safari-on-os-x-or-ios-client/2007/8
Speaking of unusual standards...
ReplyDeleteHow is the SCTP support on Firebricks? We need this for certain 4G cells etc.
Not really started on that...
DeleteIf you use chunked encoding (which is standard in HTTP/1.1) you don't need Connection: Close for things that you can't add a Content-Length header to.
ReplyDeleteAnd speculative connections is standard - pretty much all browsers do it (they are a bit of a pain for us because our audit logs can't differentiate between unused speculative connections and failed TLS handshakes...)
Indeed. The current design does not allow for chunked, but that is something we are looking at anyway.
DeleteThe extra fun bit is HTTP/2.0 which allows connection reuse even when you're requesting something from a different domain (the UA checks that both domains resolve to the same IP addresses and that the certificate for the established connection covers the new domain).
DeleteThere used to be a site called or stole my life, recording the amount of time wasted changing perfectly good code just so it would work on ie. Sadly this appears to have gone but perhaps there are grounds for an edge stole my life site?
ReplyDelete