Project

General

Profile

Bug #755

206 partial response fails over fastcgi connection

Added by Anonymous about 13 years ago. Updated over 12 years ago.

Status:
Fixed
Priority:
Normal
Assignee:
-
Category:
core
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:
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 (diff)
Added by darix over 12 years ago

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

History

#1

Updated by darix over 12 years ago

backport r1633

#2

Updated by darix over 12 years ago

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

backported and tested.

Also available in: Atom