Pagination and HTTP caching



“’s initial blog engine worked that way. Pages URIs were made of timestamps:

The content of such a page is N documents whose timestamp is greater than or equal to 1298640310.

This scheme works pretty well, because pages can get easily cached and indexed. Pages that don’t get any update can keep the same URI forever.

An article added to the freshest page automatically causes the URI to change, without invalidating the previous URI.

Timestamps were good enough for this blog, but any increasing and globally unique identifier would be a good fit.

The downside of non-monotonically increasing ids is that while it’s easy to jump to older content (“next page”), it can be tricky to get links to previous pages (newer content) without falling into duplicate content or HTTP redirects. But for infinite scroll pagination style, it makes wonders…”

CAP: if all you have is a timeout, everything looks like a partition


, ,

“This post is a part of the CAP theorem series. You may want to start by this post on ACID vs. CAP if you have a database background but have never really been exposed to the CAP theorem. This post showing some traps in the ‘Availability’ and ‘Consistency’ definition of CAP should also be used as an introduction if you know CAP but haven’t look at its formal definition…”

Understanding Elm



Elm is an unusual programming language as first one needs to learn to think in a different paradigm (FRP). To me, one of the challenges in such a process was to gain sufficient understanding of how tasks and ports are related to each other.

Part of developing an idea in Elm involves understanding the dataflow of your program. In normal imperative programming (say in Python or Java) one essentially constructs a series of operations to perform (thus “imperative”). Whereas in Elm, you define the dataflow. There is no sequence of logical steps to define, hence the paradigm is fundamentally different.

The architectural abstractions entailed in constructing such a dataflow are: models, actions and view. The model describes the current state of your entire program at any point in time; outside of the model, there is no state and everything is ephemeral. Actions happen to the model. Acting upon a model updates it, resulting in a newer model; this is how your program handles state. Finally, the view defines how to render any model on the screen. For more information, see the Elm architecture tutorial…”

H2O is a very fast HTTP server written in C


Key Features

  • HTTP/1.0, HTTP/1.1
  • HTTP/2
    • supports the final version1
    • negotiation methods: NPN, ALPN, Upgrade, direct
    • dependency and weight-based prioritization
    • server push
  • WebSocket2
  • TLS
    • uses OpenSSL or LibreSSL
    • forward secrecy
    • AEAD ciphers including the upcoming ones preferred by Google Chrome3
    • OCSP stapling4
    • session resumption and session tickets5
  • static file serving
    • conditional GET using last-modified / etag
    • directory listing
    • mime-type configuration
  • reverse proxy
    • HTTP/1.x only6
    • persistent upstream connection
  • access-logging
    • apache-like format strings
  • graceful restart and self-upgrade


Get every new post delivered to your Inbox.

Join 687 other followers