To get more control over the HTTP-Header i send it via WriteClient (and not via ServerSupportFunction). This works fine under IIS but under Apache WriteClient fails and GetLastError() returns 87 (invalid parameter).
I've no idea who works on mod_isapi, but I think this bug report really needs an example that demonstrates the problem. From the description, I'd have thought you could construct a HelloWorld-sized example?
Sample: DWORD WINAPI HttpExtensionProc(LPEXTENSION_CONTROL_BLOCK ecb) { char* buffer = "HTTP/1.1 200 OK\r\nDate: Sun, 11 Jul 2004 09:10:58 GMT\r\nContent-length: 0\r\n\r\n"; unsigned long bufferSize = strlen(buffer); if (!ecb->WriteClient(ecb->ConnID,buffer,&bufferSize,HSE_IO_SYNC)) { return HSE_STATUS_ERROR; }; // if return HSE_STATUS_SUCCESS_AND_KEEP_CONN; }; IIS: WriteClient works, the header is "nph-"sent. Apache: WriteClient fails.
I had a look at the code in mod_isapi.c, I changed line 687 from apr_cpystrn(newstat + 8, stat, statlen + 1); to apr_cpystrn(newstat + 8, stat, statlen); and that seemed to fix the problem for me. For the example above Apache would try to process the header line "Status: 200 OK\r\nD", and points out that "D" is not a valid header.
I don't think this is actually the problem. I use WriteClient to dump out a complete HTTP response which includes header and body in the first chunk that gets passed to WriteClient. The header might look like this: <pre> HTTP/1.1 200 OK Content-type: text/html; charset=utf-8 Content-Length: 3042 ... some HTML text goes here. </pre> This works perfect with IIS, but not with Apache. I get the same 87 error as mentioned above. There's definitely more going on here than just an extra character in the header block...
Created attachment 18374 [details] Patch to not clobber the ISAPI's response code. I've attached a patch to 2.2.2's mod_isapi.c which should correct this behavior. I've run it against a suite of ISAPI extensions, all of which give their correct responses as far as I can tell. What seems to be the issue is that ap_scan_script_header_err_strs likes to return 0 (or some other value which is not the HTTP status). The current mod_isapi sticks this result in as the HTTP status. Needless to say, this is quite unexpected. Since mod_isapi's send_response_header already gets the correct value, there's no reason that I can see to second-guess it. If someone can review this trivial patch for sanity, I'd appreciate it. I can't find any breakage, but I assume that someone did that for a reason.
Created attachment 18375 [details] More correct patch, cribbed from mod_cgi On the advice of wrowe, I've attached a more correct patch which cribs from mod_cgi. As a rule, we probably don't want to use the return from ap_scan_script_header_err_strs. But if it's non-zero, we should. The last patch neglected a case, as well. This one should catch everything. Again, I ran it through its paces and was able to get a variety of responses.
See bug 16637 for an interrelated issue.
Created attachment 18392 [details] Complete logic overhaul for send_response_header This updated patch completely replaces the HTTP response status logic in send_response_header. It likely should correct the issue mentioned in bug 16637 as well.
This looks great. Please review trunk, I've refactored this a bit to make the interrelations between r->status and dwStatus a bit clearer.
I hate when I can't track this stuff down. The commit to trunk which is expected to resolve this is 416272
Will Rowe has posted a zipfile containing compiled mod_isapi modules which include the patch correcting this bug (for use with 2.0.58 and 2.2.2), for testing purposes. It is available at: http://people.apache.org/~wrowe/mod_isapi-416293.zip You may read his full email to the dev@httpd.apache.org list here: http://marc.theaimsgroup.com/?l=apache-httpd-dev&m=115206683718140&w=2 If you test this version of mod_isapi, please post your feedback to the dev@httpd.apache.org list. Your feedback will help ensure that there are no regressions or other issues in this version of mod_isapi.