https://issues.apache.org/bugzilla/show_bug.cgi?id=54914
--- Comment #2 from Chris Darroch <[email protected]> --- I haven't proposed this patch for backport to 2.4.x yet because it doesn't deal with OPTIONS, and I don't yet have a solid proposal on that front. With 2.2.x and 2.4.x, OPTIONS on a directory (e.g., "OPTIONS / HTTP/1.0") would return variable Content-Type response header values, depending on whether a DirectoryIndex file was found by mod_dir. If found, the Content-Type was derived from the index file (e.g., text/plain or text/html). If not found, the supposedly internal MIME type httpd/unix-directory is returned (which is arguably an error, but a long-standing one). With this patch, httpd/unix-directory is always returned, even if a DirectoryIndex file exists. Personally, I think it would be preferable to either: a) Restore (in trunk) the long-standing but arguably incorrect behaviour in which httpd/unix-directory is only returned if no DirectoryIndex file is found, or b) Adjust mod_dir and/or other modules so that httpd/unix-directory is never returned (e.g., by not returning Content-Type at all when r->content_type is set to an internal MIME type). While (a) might be the "safer" option, it may also may be harder or uglier to implement, with additional workarounds for the fact that r233369 (PR 25435) ended up breaking a number of other standard behaviours (e.g., PR 53794). This is because that change (r233369) lets mod_dir proceed with its internal redirect to the DirectoryIndex file, as if it was always the canonical handler for the request, but retains some aspects of the original request, like the method and original handler setting. When the original handler was never set, or can work equally well with a directory as with an index file, there's no problem; indeed, it can be a feature. (This is what the reporter of PR 25435 wanted for their mod_perl setup.) But when the original handler is set and the system is not expecting to have the request rewritten to point to an index file (e.g., mod_dav, mod_rewrite), things go awry. -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
