Hi Jörg,
>> What I meant with "cannot be solved" was that it appeared that you
did
>> not want to solve it.
> While I don't exactly recall the issue you mention, be aware that we
don't
> ignore your feedback. IIRC, Matt explicitly said that we should
modify
> uri_to_file to follow Apache's behaviour. It was just not done yet,
since
> like most open source projects, it is done in spare time.
I understand that - and I'm full of respect for all of you making such
splendid products.
However, I might have misunderstood you: When I complained that
DirectoryIndex would only take a single parameter - and that I needed
more - you answered in two ways: By adding an error message stating that
you cannot have more than one parameter, and by telling me that I should
use typeless_uri instead. You also assured me that the latter would
solve my problem.
But it won't: First of all, I want to use .odt files for ordinary
webcontent, and your typeless_uri doesn't allow for that. I could modify
it, of course, but then we're back to the old story. But at the same
time, simply adding .odt as an extension on your list still wouldn't
solve my basic problem, as I would like to be able to add an arbitrary
number of extensions for different fileformats - and the crucial problem
for me would be that I sometimes need tight control over the order that
extensions are checked.
An example: When "upgrading" a website from pure HTML to XML and
OpenDoc files, I might in the beginning want an index order of
'index.html index.odt' to let the customer experiment with the new
layout by specifying an explicit path, whereelse ordinary users still
see the old pages. At a later stage, I might swap the order to let all
users benefit from the new OpenDoc files when they exist and otherwise
see the old HTML pages.
Apache has worked like this for years, you have the choice and the
flexibility to do so if you please, but it appeared to me that your
message was: No, either you use a single index file, or otherwise use
typeless URIs. Whilst I can follow and sympathise with the latter, it
isn't always possible in the real world, and I want the flexibility to
choose the solution I want ;-).
> The idea is that plugins are small enough so that it won't hurt you
if you
> use different/older code:
Correct. But neither would I benefit from updates to said code - should
it ever happen. And I think there is room for improvement - among other
things I want to add support for the HTTP ETag for better caching
support. Yes, I _am_ very cache aware - my environment needs it badly
;-)
>> And the changed line? I tried setting the last modified header in
my
>> plugin, however, serve_file insisted on loading the mtime from the
temp
>> file and overwrite the value I supplied. The result beeing, of
course,
>> that browsers would reload the pictures all the time as the temp
file
>> would always have a new mtime.
> I'm quite interested in what you did, maybe the patch is generic
enough
> to be included in the next version?
my $mtime = $client->headers_out->header("Last-Modified") ?
$client->headers_out->header("Last-Modified") :
http_date((stat(_))[9]);
In that way serve_file respects the attribute if it has been set
explicitly by a plugin earlier up the foodchain.
> Where exactly? What questions did occur to you, [...]
Try looking at my earlier mails to this list ;-)
Regards,
Lars
--
Lars Skjærlund
Skovengen 111
2980 Kokkedal
Denmark
Tel.: +45 70 25 88 10
http://www.skjaerlund.dk/lars
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
