problem with validated site

"André Gillibert" <tabkanDELETETHISnaz (AT) yahodeletethato (DOT) fr> writes:

John L. wrote:
I highly recommend learning PHP, even if you only learn the basics,
as even a little bit of server-side scripting can go a long way.

Although, it's too easy to write insecure PHP once you go past the
very basics. As long as you stick to include('filename'); and don't do
anything with variables it should be safe, though.

But for static pages for which server side scripting would be used for
maintainance purposes, they've tradeoffs:

I don't really disagree with any of this, and especially not with your
suggestion to use HTML preprocessing rather than server-side scripting
if all that's wanted is a templating engine.

On the other hand, it is possible to use server-side scripting and
make the pages *look* static to the end user, which is obviously
worthwhile for those pages that need to be dynamic but aren't
inherently uncacheable.

http://www.mnot.net/cache_docs/ is (still) a good page on the subject.

1) HTTP cache control. For example, conditional GET operations will
always think that documents have been changed and reload them.
The HTTP cache control mechanism is really subtle. A large part of
RFC-2616 deals with it. Dynamic pages break that.

With Apache 2.2 and CGI setting a Last-Modified header in the CGI
script is sufficient to get proper 304 responses on If-Modified-Since.

You also get arguably easier control over Cache-Control with
server-side scripting than with .htaccess.

2) Typically, the server don't send a compressed stream for dynamic
resources even if the user agent declares a Accept-Encoding header
including gzip, compress or other compression algorithms.
Compression can reduce by 3 or 4 the file size! Both the server and
client benefit from this!

Again, Apache 2.2 and CGI works fine with Accept-Encoding: gzip at
least. I've not tested the others.

3) HTTP 1.1 partial downloading is very unlikely to work with dynamic
content. This does matter for big files only. Below 400 kilobytes,
it's not very important.

If a web page is above 400kb it could probably do with splitting
anyway! Something to bear in mind for dynamically-generated images,
though, where a useful compromise is to dynamically generate it the
first time, then save it to local storage and in future generate links
to the stored copy.

4) The Content-Length attribute won't be specified, though it can help
the user agent. e.g. User agents use it to display a progress bar and
automatically, or with user help, they may choose to stop downloading
the resource if it's too large or to use an alternative download
manager.
Actually, the HEAD method looses of its usefulness if the
Content-Length attribute disappears.

There's nothing to stop server-side scripts from doing:
page = generateContentsOfPage();
setResponseHeader("Content-Length",length(page));
print(page);

Whether that's a sensible way to do things depends on the language. In
the scripting languages that encourage interleaving of code and HTML
tags (<?php ?>, <% %>, etc) it's probably fighting the paradigm too
much. In an XSLT or other document-tree based language or library then
it's pretty straightforward.

For some scripts it might not be appropriate to do this, of course.

Other minor detail: The Content-MD5 won't be provided while it could
be useful on unreliable connections.

I don't see this header even on static files. Maybe I just haven't enabled
it in the Apache config, though.

--
Chris

Chris Morris wrote:
<snip>

On the other hand, it is possible to use server-side scripting and
make the pages *look* static to the end user, which is obviously
worthwhile for those pages that need to be dynamic but aren't
inherently uncacheable.

snip
With Apache 2.2 and CGI setting a Last-Modified header in the CGI
script is sufficient to get proper 304 responses on If-Modified-Since.

Very interesting. This can be implemented without any client or server
performance tradeoff.

You also get arguably easier control over Cache-Control with
server-side scripting than with .htaccess.

Yes, but I think the OP only needs a basic resource control. He didn't ask
for advanced features.

2) Typically, the server don't send a compressed stream for dynamic
resources even if the user agent declares a Accept-Encoding header
including gzip, compress or other compression algorithms.
Compression can reduce by 3 or 4 the file size! Both the server and
client benefit from this!

Again, Apache 2.2 and CGI works fine with Accept-Encoding: gzip at
least. I've not tested the others.

This has performances tradeoffs for the server. That's why most dynamic
sites don't do that.
If Apache is clever enough not to recompress the file when the
Last-Modified header is set to a date older than Apache's cache for this
resource, than, it's perfectly fine.
If not, then, the performance cost will be acceptable on small and medium
servers (e.g. recieving 20000 requests every day), but may be serious for
large servers (millions of requests every day).

3) HTTP 1.1 partial downloading is very unlikely to work with dynamic
content. This does matter for big files only. Below 400 kilobytes,
it's not very important.

If a web page is above 400kb it could probably do with splitting
anyway!

Yes. Sometimes having a whole book in a single page can be handy, though.
I like the RFC on ietf.org. They're stored in a single document. It's
handy to search in them.
The HTML5 drafts are a good example of big one-page document. It's not too
bad.

<snip>

Actually, the HEAD method looses of its usefulness if the
Content-Length attribute disappears.

There's nothing to stop server-side scripts from doing:
page = generateContentsOfPage();
setResponseHeader("Content-Length",length(page));
print(page);

Good point. For most dynamic pages, the computation time is tiny (a few
milliseconds), so, the fact that the data is entirely pre-computed before
being sent isn't a problem. This is even more true for quasi-static pages,
for which the computation time is probably less than one millisecond.

Whether that's a sensible way to do things depends on the language. In
the scripting languages that encourage interleaving of code and HTML
tags (<?php ?>, <% %>, etc) it's probably fighting the paradigm too
much.

This is the main problem. Doing things correctly with server side scripts
is possible, but requires some knowledge and skill (that you've just
shown). Actually, server side scripting encourages poor cache control and
size information. This is why most dynamic pages on the web aren't very
good.

Other minor detail: The Content-MD5 won't be provided while it could
be useful on unreliable connections.

I don't see this header even on static files. Maybe I just haven't
enabled it in the Apache config, though.

Yes, there's the ContentDigest directive.

http://httpd.apache.org/docs/2.0/mod...#contentdigest
It isn't available for SSI or script documents.
Currently the values aren't cached. That's not nice.
Anyway, that's a detail.
If the Content-MD5 was supported by more servers, some user agent could
use it to prevent the re-loading of resources (e.g. small icons) that are
stored locally on many different web servers, even though they're
identical.

In conclusion:
It's possible to write good cacheable dynamic pages, without client-side
tradeoff, and with an acceptable server-side tradeoff. Sticking to static
pages may help inexperienced administrators to "get it right".

For sites hosted by third party servers, other factors should be
considered:
Are some sort of scripting or SSI allowed?
If yes, how much scripting execution power do you get?
How much do you control the URI of the dynamic resources? For URI
stability and transparency, things like
http://www.somewhere.com/index.php?page=hello.html are not as good as
http://www.somewhere.com/hello.
How many requests do you expect to get every day?
What server is it and how much can you change its configuration?
e.g. The server may not support the compressed encoding for dynamic pages
or may not give access to the relevant configuration files.

--
If you've a question that doesn't belong to Usenet, contact me at
<tabkanDELETETHISnaz (AT) yahoDELETETHATo (DOT) fr>