| Subject: | Responses without a Content-Length header aren't parsed |
HTTP responses without either a Content-Length header or chunked
encoding are not parsed. This is possibly the correct RFC compliant
way, as 14.13 [1] says that a server SHOULD include this header unless
there are reasons in 4.4 [2] that prohibit it. However, some servers do
not include it.
It seems that point 5 in section 4.4 allows this sort of processing, if
a Content-Length header is not present. The transfer length may be
determined:
"5.By the server closing the connection."
I have left the check for strict_compliance commented out, but would
like comments on whether this is a good idea.
1 - http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.13
2 - http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.4
| Subject: | 20080312-http-parser-no-content-length.patch |
--- /data/tmp/HTTP-Parser-0.04/Parser.pm 2007-11-10 22:39:21.000000000 +0000
+++ /usr/local/share/perl/5.8.8/HTTP/Parser.pm 2008-03-12 13:22:57.000000000 +0000
@@ -74,7 +74,7 @@
$p{request} = 1 unless exists $p{response} or exists $p{request};
die 'must allow request or response to be parsed'
unless $p{request} or $p{response};
- @p{qw(state data)} = ('blank', '');
+ @p{qw(state data strict_compliance)} = ('blank', '', 1);
my $self = bless \%p, ref $class || $class;
return $self;
}
@@ -277,6 +279,18 @@
}
}
+ # perhaps we do have content, but the server didn't include a length
+ # section 14.13 of the spec says "SHOULD" unless there are reasons not
+ # to, some bad servers still don't include one
+ if(length $self->{data} && !defined $obj->header('content_length')) {
+ # FIXME: possibly die here unless the user specifically asks us to be non-compliant
+ # die "no content-length header but we still have content" if $self->{strict_compliance};
+
+ # FIXME: should we set a state here?
+ $self->{obj}->content($self->{data});
+ return 0;
+ }
+
# else we have no content so return success
return 0;
}