How lift processes HTTP requests

From Lift

From David's post on the mailing list

Lift services HTTP requests in a "render pipeline".

Lift is implemented as a Filter (thanks to the excellent suggestion from Viktor).

When a request comes in, any functions defined in LiftRules.early (see LiftRules.appendEarly) are executed. This can be used to set Tomcat to UTF-8 for parameter parsing (although this is dangerous if lift is one of many Filters and the other Filters expect different behavior).

When a request comes in, the request re-writing is repeatedly applied to the request until there are no more matches in the request re-writer partial function.

The re-written request is then used to create a RequestState instance.

Next, the filter tests the request against LiftRules.isLiftRequest_? to see if there's a specific rule about the request being handled by lift.

If the request should be handled by lift, the request is passed to an instance of LiftServlet.

The request is matched against LiftRules.statelessDispatchTable and serviced if there's a match (this is useful for REST requests that are truly stateless and there's no desire to create a new Servlet Session for each request)

All of the subsequent handlers are done inside the S context (thus, they have access to session state):

• If the request matches LiftRules.dispatchTable, then the request is handled by dispatchTable.
• If the request is a Comet request, it's handled by the Comet handler.
• If the request is an Ajax request, it's handled by the Ajax handler.
• Otherwise, the request is handed off the the LiftSession for further processing:
  • In the LiftSession, the request is tested against session specific dispatchers (see S.highlevelSessionDispatcher) and dispatched if there's a match
  • Next, the request is tested against SiteMap (if SiteMap is defined). If the page is guarded by SiteMap and the guard fails, then the appropriate response is sent to the browser
  • Otherwise, the template for the incoming request is located:
    • First, the LiftRules.templateTable is consulted (this is a method which combines session specific template lookup with LiftRules-based template lookup). If the template is located, it's returned
    • Otherwise, the parts of the path that start with '.', '_' or contain '-hidden' are removed and the resource is looked up in LiftSession.findAnyTemplate
    • findAnyTemplate looks for a given named resource (given suffixes and locales). If the resource cannot be located, a class and method are searched for in the "valid packages".view packages
    • Once the template is located, it is processed by processSurroundAndInclude.

---

This is the older version of that page with some more implementation details (but with the warning below)

WARNING this information is somewhat out of date

lift implements a Servlet. When the Servlet's “service” method gets called, lift does the following:

• If the request is a GET, lift looks to see if the file name suffix is "png", "js", "css", "jpg", "ico", "gif", "tiff", "jpeg" and that the file exists. If so, lift serves the static file.
• lift iterates over functions added with Servlet.appendEarly This allows, for example, setting the req.setCharacterEncoding("UTF-8")
• lift recursively pattern matches rewrite rules defined with Servlet.addRewriteBefore and Servlet.addRewriteAfter The rewrites are partial functions (case statements) that allow you to pattern match the URI, a list of the path elements, the HTTP request, and the request type and return a re-written URI, path, and parameters. This pattern is recursively applied. So:

  case (_, “foo”:: bar :: _, _, _) => (“/foo”, List(“foo”), TreeMap(“param” -> bar))

  Will find all requests that start with “foo” and turn the second part of the path into a parameter named “param”
• lift then attempts to match patterns with patterns defined with Servlet.addDispatchBefore and Servlet.addDispatchAfter If any patterns are matched, lift creates a thread-local “S” state and invokes the function. The response from the function is matched in the following way:
  • Response instance – return it
  • NodeSeq – treat as XHTML, fix the references (img, a, form, etc. tags) and generate a Response with type “text/html” and code 200
  • XmlResponse – create a Response with type “text/xml” and code 200
  • Otherwise return a “404 Not Found”
  • Return the response
• Find/create a Session Actor for the current Servlet session
• Drain any pending items from the current thread's inbox
• Set the timeout for the request (10 seconds for normal, 100 seconds for AJAX request)
• Send an “AskSessionToRender” message to the Session and wait for the maximum time for a response. If no valid response is returned, response with a 404. If the session sends a “Response” process it and return it as the HTTP response.