www-apache-bugdb mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Taketo Kabe <k...@sra-tohoku.co.jp>
Subject mod_include/7636: byterange on SSI puts excess buckets after error response
Date Thu, 26 Apr 2001 18:17:31 GMT

>Number:         7636
>Category:       mod_include
>Synopsis:       byterange on SSI puts excess buckets after error response
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    apache
>State:          open
>Class:          sw-bug
>Submitter-Id:   apache
>Arrival-Date:   Thu Apr 26 11:20:00 PDT 2001
>Originator:     kabe@sra-tohoku.co.jp
>Release:        2.0.17-alpha

SunOS masamune 5.8 Generic_108528-05 sun4u sparc SUNW,Ultra-60
gcc version 2.95.2 19991024 (release)

httpd-2_0_17-alpha --enable-include --enable-cgid


When you request a byterange on SSI file, the response will
put excess things after proper response head/body on
"416 Request not satisfiable" error.

This will screw Keepalive byte syncronization, as the excess
are not included in Content-Length.

One problem is that for byterange range checking, the BYTERANGE
filter uses original file's size (not the size after SSI process)
for upper bound checking...but it's not a big deal for now
(This is because (request_rec*)r->clength is set to filesize by
 default_hander() and mod_include/INCLUDE filter didn't reset this)

When you request a byterange starting beyond the filesize,
byterange filter correctly (or incorrectly, whatever) detects this
as out-of-bound and responds 416, sending out an error bucket and EOS
down the filter chain.

(Now for my guessing, not proved)
After the byterange filter returns from ap_pass_brigade(),
INCLUDE filter which is an upstream, continues to push on
the remaining contents.
This appears as the excess things after the error response body.

INCLUDE -------------> BYTERANGE --------> CONTENT_LENGTH .....
	pass initial bucket
	(likely things before
	 SSI tags)
		checks for byterange;
		it's out of range
		so send out 416 error bucket,
		remove itself from filter chain

					error bucket propagated down,
					returning 416 error response

		return from ap_pass_brigade()

	return from ap_pass_brigade()
	continue to push remaining
	buckets (the #exec and
	other trailing things)

					excess things tacked after
					error response

To fix this, I guess we need to have a way to notify the UPSTREAM filters,
not just downstream filters by sending down EOS, that the filter chain
has stuck.
((request_rec*)r->eos_sent is not designed for this so you can't use it)

CGI and plain files also could have suffered from this, but fortunately
these currently only use a single bucket and had nothing to push 
after the error.


* Prepare an SSI file with perhaps #execs
  (having mod_include split it into multiple buckets is important I guess)

	<!-- doublequote needed for cmd param for Apache1 -->
	<!--#exec cmd="/usr/ucb/printenv" -->

* Then retrieve this with a byterange request, which starts
  beyond the size of the original file:
	GET /whereever/youve/putit.shtml HTTP/1.0
	Range: bytes=200-

* The result will be 416 (for roughly the same reason for PR#7635),
  but excess things (likely everything after #exec) will be 
  appended to the response after the error body.


kabe% telnet 80
Connected to localhost.
Escape character is '^]'.
GET /~kabe/t/c.shtml HTTP/1.0
Range: bytes=200-

HTTP/1.1 416 Requested Range Not Satisfiable
Date: Thu, 26 Apr 2001 17:34:21 GMT
Server: Apache/2.0.16 (Unix)
Content-Length: 387
Connection: close
Content-Type: text/html; charset=iso-8859-1

<TITLE>416 Requested Range Not Satisfiable</TITLE>
<H1>Requested Range Not Satisfiable</H1>
None of the range-specifier values in the Range
request-header field overlap the current extent
of the selected resource.
<ADDRESS>Apache/2.0.16 Server at www.bio.is.tohoku.ac.jp Port 80</ADDRESS>
DATE_GMT=Thursday, 26-Apr-2001 17:34:21 GMT
DATE_LOCAL=Friday, 27-Apr-2001 02:34:21 JST


 [In order for any reply to be added to the PR database, you need]
 [to include <apbugs@Apache.Org> in the Cc line and make sure the]
 [subject line starts with the report component and number, with ]
 [or without any 'Re:' prefixes (such as "general/1098:" or      ]
 ["Re: general/1098:").  If the subject doesn't match this       ]
 [pattern, your message will be misfiled and ignored.  The       ]
 ["apbugs" address is not added to the Cc line of messages from  ]
 [the database automatically because of the potential for mail   ]
 [loops.  If you do not include this Cc, your reply may be ig-   ]
 [nored unless you are responding to an explicit request from a  ]
 [developer.  Reply only with text; DO NOT SEND ATTACHMENTS!     ]

View raw message