Re: Re: PHP taint support: first results
| From: | Stut | Date: | Fri, 05 Oct 2007 18:49:13 +0000 |
| Subject: | Re: Re: PHP taint support: first results | ||
| References: | 1 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-32660@lists.php.net to get a copy of this message | ||
Wietse Venema wrote:
Rasmus Lerdorf: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. -Stut -- http://stut.net/Wietse Venema wrote: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.Rasmus Lerdorf: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.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.