I've noticed that there is nothing in my /tmp/luci-modulecache
directory. Digging into it it looks like because both the expected uid
and mode of the files doesn't match, so for security reasons they're
long being loaded or saved by ccache.lua (from the luci-lib-core
package). I'm not sure how far back this has been broken but I it
appears to have been quite some time, possibly years?
I've included a patch which updates the checks to use the right newer
function name / structure name. It decreases page load times by about
10-15% on my bcm2708 (raspberrypi). I can create a ticket if you'd
prefer. The patch is against the luci-0.11 branch but should apply to
trunk as well.
Signed-off-by: Bryan Mayland <bmayland@leoninedev.com>
The nixio library can mistakenly build without shadow password support due to the
compile-time test failing.
Because the test for HAS_SHADOW in the nixio Makefile uses the default CC flags,
the test may attempt to cross-compile with different VFP abi than libc does and
will therefore not link. Passing CCFLAGS on the command line builds the test
correctly and will enable HAS_SHADOW if available.
The validity of authentication tokens was determined by the
mtime of respective authentication tokens on filesystem
stored in $sessionpath.
Talking about hardware without RTC or without a prior
connection to a time server, date/time usually around 1970 -
so is the mtime of the authentication token file in
$sessionpath.
When now configuring an internet connection via LuCI, the
system might fetch the current date/time (e.g. via ntp)
which invalidates the token, returns "403 Forbidden" and
kicks the user out of the interface.
This patch changes the authentication system to use time values
based on the uptime of the machine - rather than values based upon
gettimeofday() and {a|m}time values - and save them inside the token.
That way can always determine the difference between login
(last interaction respectively) and the current time, in-
dependant of the system clock jumping backwards/forwards.
Warning: This patch removes the clean() function and respective calls.
This means, invalid tokens will NOT be determined and removed from
filesystem automatically anymore.
Before, every HTTP-call caused a scan for invalid tokens,
which is quite expensive. Instead consider using a cron job
deleting all stalled files periodically.
Contributed by T-Labs, Deutsche Telekom Innovation Laboratories
Signed-off-by: Mirko Vogt <mirko@openwrt.org>
Hi,
The attached patch fixes the JSON generation when dealing with NaN (not
a number), this makes the JSON parsing in the web browser succeed
(before it would get a "nan" which is not a valid JS value)
Chris
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.
