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 2003/01/31 14:14:52 UTC

DO NOT REPLY [Bug 16637] New: - ISAPI: HTTP 200 OK error response is still returned

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

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16637

ISAPI: HTTP 200 OK error response is still returned

           Summary: ISAPI: HTTP 200 OK error response is still returned
           Product: Apache httpd-2.0
           Version: 2.0.44
          Platform: PC
        OS/Version: Windows XP
            Status: NEW
          Severity: Normal
          Priority: Other
         Component: mod_isapi
        AssignedTo: bugs@httpd.apache.org
        ReportedBy: laimis@tic.lt


Thank you for fixing the Bug#: 10216 in version 2.0.44. It stopped displaying 
HTTP 200 OK error response in very most cases.

But there is one more case when this "error" response is displayed: when ISAPI 
extension does not include any HTTP header in it response. 

We traced mod_isapi.c and found such a situation:

1. ISAPI extension calls ServerSupportFunction with '200 OK' in buf_data 
parameter, 0 in buf_size parameter, and pointer to a "null-terminated string 
pointing to optional headers or data to be appended and sent with the header" 
(excerpt from Microsoft MFC Library Reference) in data_type parameter.

2. ServerSupportFunction calls send_response_header function, and it returns 
at line 795:

    /* If only Status was passed, we consumed nothing 
     */
    if (!head_present)
        return 0;             /* <- line 795 */

    cid->headers_set = 1;     /* <- line 797 */

3. Line 797, added in version 2.0.44, is not entered, and bug fix code, added 
for correcting the buggy '200 OK' response, is not entered (line 1597). Line 
1595 returns the value 200, causing the result to run through the core die 
handler:

    /* Flush the response now, including headers-only responses */
    if (cid->headers_set) {
<...>
        cid->response_sent = 1;

        return OK;  /* NOT r->status or cid->r->status, even if it has 
changed. */
    }
    
    /* As the client returned no error, and if we did not error out
     * ourselves, trust dwHttpStatusCode to say something relevant.
     */
    if (!ap_is_HTTP_SERVER_ERROR(r->status) && cid->ecb->dwHttpStatusCode) {
        r->status = cid->ecb->dwHttpStatusCode;
    }

    /* For all missing-response situations simply return the status.
     * and let the core deal respond to the client.
     */
    return r->status; /* <- line 1595 */


Recommendations for solving the problem: move code line 797 four lines above.


Another minor problem, considering the same bug-fix code added, is that HTTP 
status code 200 is not logged in 'access.log' for all successful calls of an 
ISAPI extension, with exception to the problem described above. These 
responses are logged normally. :-)

Recommendations for solving problem: insert one line of code in mod_isapi.c, 
line 1582:

        r->status = cid->ecb->dwHttpStatusCode; /* <- line 1582 */

        return OK;  /* NOT r->status or cid->r->status, even if it has 
changed. */

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