We use URL’s every day, but as a developer we have to know a bit more about their structure and the rules that apply to them.
This article does a good job of reviewing all these rules:
One part I hadn’t realized was the “parameters” portion after the semicolon- this is apparnetly not used very frequently at all.
The article also discusses a lot of encoding and special character ruls for each portion of the url.
After upgrading to windows 8.1, i noted the message in IE that facebook had been loaded using the SPDY protocol. Pretty interesting, as I recall when this was just some theoretical ideas that google was throwing around, I had no idea it had alrady progressed this far and was actually being implemented by the major browsers. It looks like most or all of the major browser versions now support SPDY and a number of the larger service prodivers are supporting it server-side, such as google (gmail etc), facebook, etc. Twitter was an early adopter as well.
What is SPDY? read a bit more here https://developers.google.com/speed/spdy/
So now I’m curious if IIS will implement this, or perhaps it already has in the newest versions?
So WebRTC seemed to pop up out of nowhere, and now I’m seeing it all over the place.
“realtime” communication directly between browsers, enabling true peer-to-peer communications. What does that mean?
A few apps that have already popped up demonstrate what it can do:
ShareFest.me – Copy a file on your computer to another user, on another computer, in their browser. No server involved, the data is directly sent between them.
PeerCDN.com – a content delivery network that serves up content *from other browsers*. Imagine getting rid of servers and having browsers serve up files among themselves.
WebRTC effectively is a new feature of HTML5 that enables peer-to-peer serverless communications, in a generic way. This reminds me of the technology adobe releated for video sharing, using the RTMFP protocol.
At this time, it appears firefox and chrome support it, with IE lagging behind.
Browser caching is a deep topic, but I had an idea today.
One tradeoff used in browser-side caching is whether to use an expiration header or a etag header to control the browser cache.
Expiration headers can tell the browser “keep this file until this this date/time, and then you can retrieve it again”.
Etags send a custom hash or number to the browser and basically say “check with the server if the file is still this version, send the new one back if not”.
The etag header allows updating files almost immediately in the browser, since the browser still sends a request everty time to chec if the file has changed.
Expiration headers don’t have this fast turnaround- if you set the date way in the future, you won’t have a way to tell the browser “hey, this file changed, please re-download it!”.
So my idea is this: why not combine the benefits of the two, and include the etag value for linked files within the tags in the html?
For instance, when I retrieve index.html, and it include a logo.png file, we could make the tag look like this:
<img src=”/logo.png” etag=”5E451FFA498″ />
Then the browser can check this etag against the version already in the local cache, and does not need to make a request to the server for each file to re-check the etag on the files.