Project

General

Profile

Actions

Bug #2537

closed

204 response makes lighttpd to wait for ~5s

Added by glen over 11 years ago. Updated over 11 years ago.

Status:
Invalid
Priority:
Normal
Category:
-
Target version:
-
ASK QUESTIONS IN Forums:

Description

this may be similar to 1.5 ticket:
http://redmine.lighttpd.net/issues/2497

the Connection: close and Content-Length: 0 are not needed, but i added to be sure these are not the issue. i also tested with HTTP/1.0 and HTTP/1.1 both, no difference.

php-fcgi test:

<?php
header('HTTP/1.0 204 No Content');
header('Cache-Control: no-store, no-cache, must-revalidate');
header('Connection: close');
header('Content-Length: 0');
exit(0);

output:

$ wget -O /dev/null -S --tries=1 --cache=off --no-check-certificate 'localhost/stats.php?$(date +%s)'
--2013-12-06 16:33:13--  http://localhost/stats.php?$(date%20+%25s)
Resolving localhost (localhost)... 127.0.0.1
Connecting to localhost (localhost)|127.0.0.1|:80... connected.
HTTP request sent, awaiting response... 
  HTTP/1.1 204 No Content
  Cache-Control: no-store, no-cache, must-revalidate
  Connection: close
  Content-type: text/html
  Date: Fri, 06 Dec 2013 14:33:13 GMT
  Server: lighttpd/1.4.32 (PLD Linux)
Length: unspecified [text/html]
Saving to: ‘/dev/null’

    [       <=>  ] 0           --.-K/s   in 5,7s    

2013-12-06 16:33:19 (0,00 B/s) - ‘/dev/null’ saved [0]

ruby test:

#!/usr/bin/ruby
require "fcgi" 

FCGI.each {|request|
  out = request.out
  out.print "Status: 204 No Content\r\n" 
  out.print "Content-Type: text/plain\r\n" 
  out.print "Cache-Control: no-store, no-cache, must-revalidate\r\n" 
  out.print "Connection: close\r\n" 
  out.print "Content-Length: 0\r\n" 
  out.print "\r\n" 
  request.finish
}

output:

+ wget -O /dev/null -S --tries=1 --cache=off --no-check-certificate 'localhost/test204.rb?1386342294'
--2013-12-06 17:04:54--  http://localhost/test204.rb?1386342294
Resolving localhost (localhost)... 127.0.0.1
Connecting to localhost (localhost)|127.0.0.1|:80... connected.
HTTP request sent, awaiting response... 
  HTTP/1.1 204 No Content
  Content-Type: text/plain
  Cache-Control: no-store, no-cache, must-revalidate
  Connection: close
  Date: Fri, 06 Dec 2013 15:04:54 GMT
  Server: lighttpd/1.4.32 (PLD Linux)
Length: unspecified [text/plain]
Saving to: ‘/dev/null’

    [       <=>    ] 0           --.-K/s   in 5,7s    

2013-12-06 17:05:00 (0,00 B/s) - ‘/dev/null’ saved [0]

note the "in 5.7s" in output, the request ran for 5+ seconds


Files

2013-12-08_15.23.58-2537-1.png (35.6 KB) 2013-12-08_15.23.58-2537-1.png glen, 2013-12-08 14:25
2013-12-08_15.25.15-2537-2.png (59.6 KB) 2013-12-08_15.25.15-2537-2.png glen, 2013-12-08 14:25
apache.png (62.7 KB) apache.png glen, 2013-12-08 17:45
firefox.png (91.8 KB) firefox.png glen, 2013-12-08 17:52
2013-12-08_15.23.58-2537-1.png
2013-12-08_15.25.15-2537-2.png
apache.png
firefox.png
Actions #1

Updated by stbuehler over 11 years ago

  • Status changed from New to Invalid

This is a wget bug; a 204 response never has a body.

The 204 response MUST NOT include a message-body, and thus is always
terminated by the first empty line after the header fields.

lighttpd removes any Content-Length from the response in that case, and I see nothing wrong with that.

lighttpd does not remove the "Connection" header, which you could argue it should; OTOH a fastcgi backend shouldn't emit HTTP connection related headers in the first place.

Updated by glen over 11 years ago

2013-12-08_15.23.58-2537-1.png
2013-12-08_15.25.15-2537-2.png

This is a wget bug; a 204 response never has a body.

this also happens in browser, why i start researching it. chrome reports "cancelled" for such requests

Actions #3

Updated by stbuehler over 11 years ago

The HTTP spec is still pretty clear about it. While we could send a "Content-Length: 0" header along with a 204 response, this would basically tell the client that the Content-Length of the requested variant is updated to 0, and that doesn't make any sense.

[...] The
response MAY include new or updated metainformation in the form of
entity-headers, which if present SHOULD be associated with the
requested variant.

(Content-Length is an entity-header)

Your picture shows the "Connection: close" header, and I already told you it is a bad idea to send it from PHP, as lighttpd doesn't actually close the connection, but the header indicates it should.

Actions #4

Updated by glen over 11 years ago

apache.png

here's how apache sends out such php script (attached screenshot apache.png):

<?php
header('HTTP/1.0 204 No Content');
header('Cache-Control: no-store, no-cache, must-revalidate');
exit(0);

and wget to same apache served request:

$ hdrs varnish.delfi.lan/stats.php?$(date +%s) 
--2013-12-08 18:46:12--  http://varnish.delfi.lan/stats.php?1386521172
Resolving varnish.delfi.lan (varnish.delfi.lan)... 192.168.3.105
Connecting to varnish.delfi.lan (varnish.delfi.lan)|192.168.3.105|:80... connected.
HTTP request sent, awaiting response... 
  HTTP/1.0 204 No Content
  Date: Sun, 08 Dec 2013 16:46:12 GMT
  Server: Apache
  Cache-Control: no-store, no-cache, must-revalidate
  Content-Length: 0
  Connection: close
  Content-Type: text/html
Length: 0 [text/html]
Saving to: ‘/dev/null’

    [ <=>      ] 0           --.-K/s   in 0s      

2013-12-08 18:46:12 (0,00 B/s) - ‘/dev/null’ saved [0/0]
Actions #5

Updated by glen over 11 years ago

firefox.png

firefox (iceweasel 23.0.1) acting on same page with apache vs lighttpd. looks like firefox doesn't mind neither responses.

Actions

Also available in: Atom