The Chrome web browser revalidates every resource if no explicit Cache-Control or Expires HTTP/1.1 header is sent. This makes the page loads appear to take a long time on pages with a few external resources, adding 300-500ms
per item. This includes the XHR json responses that set page images, like wireless signal indicators and the like-- the images are revalidated on every XHR response. As an example, the Network -> Interfaces page generates 16
requests to the lucid http server:
Main HTML
cascade.css
xhr.js
tabbg.png
cbi.js
loading.gif
ethernet_disabled.png
reload.png
reset.gif
edit.gif
remove.gif
add.gif
bridge.png
vlan.png
wifi.png
iface_status
Of those, 14 should be pulled from cache but they are all valdiated. The lucid server returns the correct 304 (Not Modified) responses but it delays the apparent page load time because of the backlog it creates at the http
server.
I would suggest setting explicit cache control on all files returned by the lucid http directory dispatcher. The "Expires" header is reportedly more widely supported, however this relies on the clock on the OpenWrt? system
being accurate, which may not be the case. The "Cache-Control: max-age=" allows the server to set a timeout in seconds. I've included a patch that sets revalidate interval to 1 year, which is the value recommended by google.
Reference: http://code.google.com/speed/page-speed/docs/caching.html
Note this could create an issue if there are luci application which are generating files which change that are being served by the lucid http DirectoryPublisher?. I'm not sure if there is anyone doing that. If needed, this can
probably be created as an option to the DirectoryPublisher? config stanza for each vhost.
Finally, this only affects the Google Chrome browser, as both IE9 and Firefox seem to have their own revalidation interval in the absence of explicit cache control which may be based on the last modified time of the resource.
Even in Chrome, this change doesn't take effect until the item is re-served with a 200 HTTP response so Chrome's cache should be cleared after this patch is applied. The patch can be extended to include cache control on 304
responses, but I'd not worry about cluttering the code with it because the problem will solve itself once chrome redownloads the resource.
The commit adds a recursive parser for datatype expressions which allows nesting of validators,
this allows for complex expressions like "list(or(range(0,65535),'infinite'))" to allow a list of
values which are either integers between 0 and 65535 or the literal string "inifinite".
That change also deprecates combined datatypes like "ipaddr" ["or(ip4addr,ip6addr)"] or
"host" ["or(hostname,ip4addr,ip6addr)"]
For SimpleSection, use the section name (always "1") instead of the
section type in the CBI-like string used to identify the upload. This
allows upload fields to be placed in SimpleSections. The fix changes a
minimal number of lines, but does introduce some unnecessary confusion,
it may or may not be better than a more thorough/invasive fix.
Set the enctype for the form element in the simpleform view to be
multipart/form-data because the default
application/x-www-form-urlencoded does not support input files.
Signed-off-by: Kevin Locke <kevin@kevinlocke.name>
