I think both arguments carry some weight. yes, programmers should be responsible for not validating data from clients and, in general, it's not our problem to save them from bad programming practices.I suppose the opposition is that well, mod_perl is just an API, and we shouldn't be forcing programming styles onto the programmer, but there isn't a single legitimate use of \n in an outgoing header, so I don't think that argument has much weight.
Thoughts?
If that causes a bug, may be this should be fixed in Apache?
So, because a programmer doesn't check the validity of the input he gets
it's a bug that should be fixed in Apache? Maybe someone should make
sure that the same thing can't happen with allowing CGI input going straight into a form.. oh wait. I don't see anyone from dev@httpd wanting to "fix" this bogus error when
it's really just doing what the programmer wants to do (when he is not
validating the input). Tables should have the ability to store both \r
and \n's IMHO.
however, for HTML-based data we give them utilities, and the problem is well known. I can't remember the last time we told users to chomp variables they put in the headers_out table :)
we could probably throw a warning if there are embedded newlines in the string sent to headers_out() and err_headers_out(), but that seems like way too much regex parsing. and I can't think of a better way than that since, yes, tables should be allowed to hold any string.
I'd probably just vote to publicize the issue on the various lists and in the guide, so it becomes rote when dealing with header setting.
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
