Bug #755
closed206 partial response fails over fastcgi connection
Description
If a fastcgi app tries to output some lengthy response with 206 partial response status then lighty will eat just the first output buffer and then close the connection. Which basically means that 206 responses from fastcgi just don't work...
I've made some digging and found this at connection.c, line 287:
case 206: /* write_queue is already prepared */ case 302: con->file_finished = 1; break;
Disabling "con->file_finished = 1" for code 206 fixes the issue. However not knowing the code at all I don't know if it's actually correct. But just by looking at how things are named I think this should be like that. Because 302 responses really don't have a body but 206's do and pretty big one usually :-)
P.S. On a simingly related note I also changed my local mod_fastcgi.c all checks for 'http_status == 200' to check for all succesful codes (status >= 200 || status < 300). I don't know if this helped anything, just making this note for completeness.
-- Maniac
Updated by darix almost 18 years ago
- Status changed from New to Fixed
- Resolution set to fixed
backported and tested.
Also available in: Atom