Re: Two OS's, two HTTPDs, two different handlings of Mime Type?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Tom Evans wrote:
On Wed, Aug 22, 2012 at 4:26 PM, J.Lance Wilkinson <jlw12@xxxxxxx> 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.Wilkinson@xxxxxxx
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/jlw12@xxxxxxx?fmt=freebusy


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx
For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx




[Index of Archives]     [Open SSH Users]     [Linux ACPI]     [Linux Kernel]     [Linux Laptop]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Squid]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]

  Powered by Linux