akuklev

`The document`	`The template`
<html wrapper="/template/common"> <head> <title>Contacts</title> <blob id="alternate-languages"> <li><a href="?lang=ru">ru</a> <li><a href="?lang=de">de</a> </blob> </head> <dl> <dt>Tel:</dt> +49 11223344 <dt>E-Mail:</dt> bla@bla.com </dl> ... </html>	<html> <head> <link rel="stylesheet" href="/style/theme.css"/> ... </head> <nav> ... </nav> <aside> <ul> <<alternate-languages>> <ul> </aside> <<body>> </html>

The document

The template

<html wrapper="/template/common">
  <head>
    <title>Contacts</title>
    <blob id="alternate-languages">
     <li><a href="?lang=ru">ru</a>
     <li><a href="?lang=de">de</a>
    </blob>
  </head>

  <dl>
    <dt>Tel:</dt> +49 11223344
    <dt>E-Mail:</dt> bla@bla.com
  </dl>
  ...
</html>

<html>
  <head>
    <link rel="stylesheet" href="/style/theme.css"/>
    ...
  </head>

  <nav>
    ...
  </nav>

  <aside>
    <ul> <<alternate-languages>> <ul>
  </aside>
  <<body>>
</html>

HTTP attachments [AEK 01622-0] What's the difference between an app and a rich web site? An app can be opened when you're offline and appears immedeatelly when you start it, while the web site needs a second o two when you're online and does not open when you're not, ...unless the whole website is in your cache. There is a modern trend in website development called client side templating: html is being served with gaps which are then filled in using ajax and updated as necessary. The main advantage is that the skeleton html becomes static resource which can be served with large cache lifetime, which closes the gap between apps and sites. The drawback is that when a user visits the page for the first time, he or she first loads the static content with gaps (second or two) and then waits another second for the gaps to fill. The solution is to provide the initial content of for the gaps right away as “attachments” to the main (skeleton) html. Each part should be served with its own E-Tag. If the request is not a simple GET, but GET-IF-MODIFIED with a list of E-Tags of already cached parts, only modified parts should be sent. Additionally we propoose a cache control extension “application” for files that should remain available for offline use until the user deliberately removes them. Example response:HTTP/1.1 200 OK Content-Length: ... Cache-Control: application; max-age=2600000 Content-Type: multipart/mixed; boundary=PART --PART Content-Type: text/html ETag: "686897696a7c876b7e" <html> <head> <title>Sweet home</title> </head> <div id="news"/> ... </html> --PART Content-Disposition: div.news Content-Type: text/html ETag: "6876696a7c876jkh" <div id="news" class="important"> Major update is comming soon: ... <div> Remark: HTTP provides excellent infrastructure for content caching. Every served file can be supplied with cache lifetime and an E-Tag. Suppose http://mydomain.com/image/kitten123.jpg is a static resource that probably will live unchanged under the same name for years. In this case the picture is served with cache lifetime of several months. Image will be cached when the client visits it for the first time and may last in the cache indefinetely long. – If the client requests http://mydomain.com/image/kitten123.jpg and cached file is not expired, it will be served immedeatelly without contacting the server. – If the client requests http://mydomain.com/image/kitten123.jpg after cache expiration, the browser would perform a GET-IF-MODIFIED request sending E-Tag of the cached version to the server. If the file was not modified, the browser would get a short and quick "NOT MODIFIED" response with new expiration date of the cached file.

S	M	T	W	T	F	S
				1	2	3
4	5	6	7	8	9	10
11	12	13	14	15	16	17
18	19	20	21	22	23	24
25	26	27	28	29	30	31

Entries tagged with webtech

Memo

Memo

Profile

December 2016

Syndicate

Most Popular Tags

Page Summary

Style Credit

Expand Cut Tags