Bug #755

206 partial response fails over fastcgi connection

Added by Anonymous about 4 years ago. Updated over 3 years ago.

Status:Fixed Start:
Priority:Normal Due date:
Assigned to:- % Done:

0%

Category:core
Target version:-
Missing in 1.5.x:

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

Associated revisions

Revision 1716
Added by darix over 3 years ago

- properly handle 206 responses generated by *cgi scripts
closes 755

History

Updated by darix over 3 years ago

backport r1633

Updated by darix over 3 years ago

  • Status changed from New to Fixed
  • Resolution set to fixed

backported and tested.

Also available in: Atom