Rasmus Lerdorf wrote:
Stut wrote:
Wietse Venema wrote:
Rasmus Lerdorf:
Wietse Venema wrote:
Rasmus Lerdorf:
Consider very common (abbreviated) code like this:

$user_data = $_REQUEST['data'];
switch($output_format) {
Question: where is the output format feature documented?

Once I know the output format is not HTML, then I know
that applying HTML-style restrictions is not appropriate.

I did search around but came up empty handed.
That's just an example.  People building REST-based web services will
typically include an output format parameter.  Or they determine the
output format based on other criteria.  It's completely up to the script
author which output format he wants to use and how he wants to make that
decision.
Would perhaps the Content-Type: information be stored somewhere in
HTTP response, or is this hopeless because of multi-part documents?

If Content-Type: header information were available, then I could use
that to choose the proper rule.

As I mentioned, I don't want to get involved with guessing games.
In that case why not assume HTML but provide a way to specify otherwise.
It could be a specific function call or using ini_set.

I don't think it's unreasonable to require scripts outputting content
other than HTML to include a line that modifies the default behaviour.
Surely the benefits far outweigh that cost.

That's already there.  They set the content-type.  The problem becomes
when they set it vs. when output goes out.  It's also very common to
turn on output buffering and buffer a bunch of stuff and then set the
content-type just before flushing the buffer.

Maybe it's enough for the tainting to switch context when a new content type is set. I'm trying to think of a situation where you might not be able to determine the requested output format because the tainting gets in the way, but I can't come up with anything. However, it would likely break a number of existing scripts which is not ideal.

-Stut

--
http://stut.net/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to