?

Log in

No account? Create an account
August 7th, 2006 - LiveJournal Development [entries|archive|friends|userinfo]
LiveJournal Development

[ userinfo | livejournal userinfo ]
[ archive | journal archive ]

August 7th, 2006

CSS-Cleaner complaint #1 - 150% worse page performance [Aug. 7th, 2006|01:31 am]
LiveJournal Development

lj_dev

[robbat2]
Introduction:

My custom S1 style (created long before the dawn of S2) uses external stylesheets of my own magic. 7 of them to be exact. Since the introduction of CSS-Cleaner, the pages load noticably slower, even when refreshed immediately (so that the styles should be coming from the hot cache at LJ). My pages used to load in 1 second, but now I'm lucky to get them in 3 seconds.

I'll make a second post with the other thing (more major) item that CSS-Cleaner has broken with my stylesheets.

Testcase #1:
  1. I set up FasterFox with the default Firefox settings, but it's display timer enabled, so I could see load times.
  2. Load my page http://robbat2.livejournal.com/calendar multiples time, determine average - 2.8 seconds over 15 runs.
  3. Edit the style to leave out all stylesheet <link> tags except one.
  4. Repeat #2, time is now 1.2 seconds over 15 runs.
  5. Notice a 1.6 second difference between the setups.
  6. Remember to set the style back the way it was originally.
Now for testcase #2, we must exclude the browser's load time of stylesheets from affecting the result.
  1. Load http://robbat2.livejournal.com/calendar, save a local copy to /tmp/calender.remote.html
  2. Produce a copy that goes direct instead of using CSS-Cleaner:
    sed -e 's,http://cssproxy.livejournal.com/?u=,,g' </tmp/calender.remote.html >/tmp/calender.local.html
  3. Load file:///tmp/calender.remote.html 15 times, average is 1.9 seconds.
  4. Load file:///tmp/calender.local.html 15 times, average is 0.5 seconds.
  5. Notice the difference is 1.4 seconds between the setups.

I think the correlation between the 1.6 and 1.4 seconds is too much of a co-incidence. CSS-Cleaner is badly slowing down my pages. If we assume 1.5 seconds is the slowdown caused by CSS-Cleaner, and that my pages used to load in 1 second (tolerance of 0.1 seconds), then we can say that CSS-Cleaner is inducing a slowdown of 150% - taking 2.5 seconds instead of 1 second.

I checked in my access_log to see if the 5 minute caching alluded to a previous post was correct, and it does seem to be reasonable true, to within 10 seconds of the 5 minute mark.

I haven't looked at the CSS-Cleaner codebase as of yet, but I'm wondering if anybody here has suggestions on the slowdown, other than reducing the number of stylesheets I use, which isn't really an option (see my next post).

link4 comments|post comment

CSS Complaint #2 - Dynamic Styles broken by CSS-Cleaner [Aug. 7th, 2006|02:03 am]
LiveJournal Development

lj_dev

[robbat2]

As per my previous post, I mentioned that I my custom S1 style uses a 7 dynamic stylesheets. In that post however, I didn't elaborate on how they were dynamic. The dynamic-ness I use serves two purposes - firstly serving different content based on your User-Agent, and secondly providing multiple cosmetic options.

The per-User-Agent part is reasonably simple, it just mainly hands out slightly different table styling so that my page looks as good as possible on every browser from Netscape4 on IRIX right thru the experimental IE7, and a lot of strange stops in-between. In a few cases, it sends different Content-Types, and other headers as well, for dealing with brokeness.

The cosmetic change part is actually what irks me more, I have functionality that allows multiple colorschemes based on a small optional cookie that says what colour scheme you like. The publically available choices are here: http://www.orbis-terrarum.net/?l=prefs (try it, and then browse my website) (For those interested in playing, a further re-use of the style engine is here: http://hotmodels.orbis-terrarum.net/?l=prefs). My S1 style is an extension of the same styling that I used for my website, and the customizable colour scheme integration is an integral part of this.

The User-Agent part isn't too hard to do with CSS-Cleaner, it just needs to send the User-Agent from the client, and keep seperate caches per User-Agent. The style part however is not solvable with CSS-Cleaner at all. The cookie is not sent by the browser to the modified URL, because the base URL domain is outside the cookie domain, and the browser rightly doesn't want to expose the cookie.

I've got one potential suggestion as to how to work around this - namely to naively use CSS-Cleaner to check, but still send the raw stylesheet URL to the browser if it checks out cleanly, but it has a major hole of a potential attacker sending 'safe' content to the cleaner and an exploit to anybody else.

Can anybody else offer other suggestions?

link8 comments|post comment

Embedded LiveJournal Recomendations [Aug. 7th, 2006|12:41 pm]
LiveJournal Development

lj_dev

[darkain]
[mood |curiouscurious]
[music |Pantera - Walk]

Embedded LJ is a feature I was unaware of until reading this previous post.

Anywho, while reading the page on Embedding LJ with PHP, something cought my eye. The last usage says you can use PHP includes, which can potentially be very harmful.
<?php
  include "http://www.livejournal.com/customview.cgi".
    "?username=darkain&styleid=101";
?>


Because PHP will actually process the contents of the document, PHP can be inserted into the LJ and PHP will see it as code. This can be tested with making a post with either of the following methods:
<? echo 'test'; ?>
or
<?php echo 'test'; ?>


While this byself may not be harmless, as in theory only the person in control of the web site is in control of the journal as well, but if their LJ is ever comprimised, then it would easily be possible to take over their personal site as well.

My recomendations would be to completely remove the the suggestion of "include" from the page mentioned above, as well as to possibly disallow any tags that start with "<?" at all, as I know its also caused some issues in the past with some browsers falsly allowing JavaScript execution as well.
link11 comments|post comment

navigation
[ viewing | August 7th, 2006 ]
[ go | Previous Day|Next Day ]