Tom Evans wrote:
On Wed, Aug 22, 2012 at 4:26 PM, J.Lance Wilkinson <jl...@psu.edu> wrote:
Eric Covener wrote:
I wonder if on the 2nd system the files are not really served by the
"default handler" and somehow end up pumped through e.g. PHP?
We've noted that NO MATTER WHERE this FilesMatch stanza appears
in the file, it never seems to be imposing the ForceType on .ram
files that clearly SHOULD be matching.
…
On both systems, the files in question are only accessible thru
a specific handler, the Adobe CQ Dispatcher.
FilesMatch and ForceType provide ways of customizing the behaviour
when you serve files through the default handler. You aren't serving
files through the default handler. Is there any difference in the
version of "Adobe CQ Dispatcher" on the two servers?
There's a 0.0.1 version difference -- Solaris running v4.0.8 and
Linux running v4.0.9. We've already determined that a VANILLA
out-of-the-box Apache configuration on Linux + the v4.0.9 dispatcher
module, and the same dispatcher configuration as on Linux or Solaris
(the dispatcher module has is own independent configuration file cited
by a module-implemented Apache configuration directive) presents the
expected mime type. There's a wide span on the Apache HTTPD versions,
Solaris being v2.2.6 and Linux being v2.2.15 (but I'm told it's
actually patched up to v2.2.22).
It's been a while, and this may be 1.3 knowledge only, but IIRC the
content type is a member of the request_rec. The default handler, if
used, uses mod_mime to determine the correct content type for the
response. If this is empty, or the default handler is not used, when
httpd comes to write the headers to the net, it will serve it with
whatever the default content type is.
Doesn't look like the request is specifying a type, but it does
specify a fully qualified path, and the file being presented back
matches that path. We know we're getting the right file, but neither
ForceType nor the fact the file extension, .ram, has a match for
the mime type of audio\x-pn-realaudio in the cited TypesConfig file
seems to be applying the correct Content-Type header on the response.
In Solaris, the same value in the TypesConfig file, the same file,
the same dispatcher configuration file, but a dispatcher v0.0.1 points
back and an Apache HTTPD at v2.2.6 renders the correct Content-Type.
It's like there's something ELSE forcing the DefaultType of text/html,
or something in the later version of Apache HTTPD or, perhaps, the
dispatcher, that makes the ForceType be ignored? Or MAYBE the
<FilesMatch> stanza isn't matching the file?
I tried pushing the LogLevel up to DEBUG, but not only is there nothing
new supplied with regard to response headers being generated in the
log file, the entire transaction has to be conducted in SSL so there's
lots of junque that's encrypted (and not interpretted) in the log.
--
J.Lance Wilkinson ("Lance") InterNet: lance.wilkin...@psu.edu
Systems Design Specialist - Lead Phone: (814) 865-4870
Digital Library Technologies FAX: (814) 863-3560
E3 Paterno Library
Penn State University
University Park, PA 16802
http://ucs.psu.edu/home/jl...@psu.edu?fmt=freebusy
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org
