You are viewing a plain text version of this content. The canonical link for it is here.
Posted to bugs@httpd.apache.org by bu...@apache.org on 2007/09/17 11:54:30 UTC

DO NOT REPLY [Bug 43386] - Default handler produces wrong content length when replacing file

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=43386>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=43386





------- Additional Comments From rahul@sun.com  2007-09-17 02:54 -------
This is easily reproducible, but is hard to fix, The reason below.

The finfo structure is populated in ap_directory_walk
---------------------------
    r->filename = entry_dir;

    cache = prep_walk_cache(AP_NOTE_DIRECTORY_WALK, r);

    /* If this is not a dirent subrequest with a preconstructed
     * r->finfo value, then we can simply stat the filename to
     * save burning mega-cycles with unneeded stats - if this is
     * an exact file match.  We don't care about failure... we
     * will stat by component failing this meager attempt.
     *
     * It would be nice to distinguish APR_ENOENT from other
     * types of failure, such as APR_ENOTDIR.  We can do something
     * with APR_ENOENT, knowing that the path is good.
     */
    if (!r->finfo.filetype || r->finfo.filetype == APR_LNK) {
=>       rv = apr_stat(&r->finfo, r->filename, APR_FINFO_MIN, r->pool);
---------------------------
]where
=>[1] ap_directory_walk(r = 0x2ba850), line 508 in "request.c"
  [2] core_map_to_storage(r = 0x2ba850), line 3471 in "core.c"
  [3] ap_run_map_to_storage(0x2ba850, 0x14, 0x0, 0xa, 0x0, 0x0), at 0x82cf0
  [4] ap_process_request_internal(r = 0x2ba850), line 150 in "request.c"
  [5] ap_process_async_request(r = 0x2ba850), line 242 in "http_request.c"
  [6] ap_process_request(r = 0x2ba850), line 288 in "http_request.c"
===========================================================
While, we open the FD in core
-------------------------
        if (r->method_number != M_GET) {
            core_request_config *req_cfg;

            req_cfg = ap_get_module_config(r->request_config, &core_module);
            if (!req_cfg->deliver_script) {
                /* The flag hasn't been set for this request. Punt. */
                ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r,
                              "This resource does not accept the %s method.",
                              r->method);
                return HTTP_METHOD_NOT_ALLOWED;
            }
        }


=>      if ((status = apr_file_open(&fd, r->filename, APR_READ | APR_BINARY
#if APR_HAS_SENDFILE
                            | ((d->enable_sendfile == ENABLE_SENDFILE_OFF)
                                                ? 0 : APR_SENDFILE_ENABLED)
#endif
                                    , 0, r->pool)) != APR_SUCCESS) {
            ap_log_rerror(APLOG_MARK, APLOG_ERR, status, r,
                          "file permissions deny server access: %s", r->filename);
            return HTTP_FORBIDDEN;
        }

        ap_update_mtime(r, r->finfo.mtime);
        ap_set_last_modified(r);
        ap_set_etag(r);
        apr_table_setn(r->headers_out, "Accept-Ranges", "bytes");
        ap_set_content_length(r, r->finfo.size);
---------------------------
]where
=>[1] default_handler(r = 0x2ba850), line 3600 in "core.c"
  [2] ap_run_handler(0x2ba850, 0x3b3b3b3b, 0x6c000000, 0x80808080, 0xff00,
0x80808080), at 0x8ba30
  [3] ap_invoke_handler(r = 0x2ba850), line 378 in "config.c"
  [4] ap_process_async_request(r = 0x2ba850), line 244 in "http_request.c"
  [5] ap_process_request(r = 0x2ba850), line 288 in "http_request.c"

While this is a bug, I think there might be other methods that rely on finfo
that get called in between, and some of them may lead to other request paths
that do not require the FD. With out significant patching, the best option may
be to redo the ap_(f)stat again once the fd is opened.


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org