Excerpts from Adam Chlipala's message of Sun Jul 29 12:37:26 -0400 2012: > Just exposing the environment variables literally doesn't sound so > appetizing: any [transaction] code would be able to read any environment > variable. There could be sensitive information in there, and it's nice > to be able to run other people's library code without worrying that it > can read sensitive information. > > Ur/Web already supports a whitelist of HTTP headers that may be read by > transactions. What do you think of a directive that maps an environment > variable name in as a specific HTTP header? Then the existing mechanism > can do double-duty via a single whitelist.
Sure; whitelist would have been my second suggestion. My one problem with overloading the HTTP header mechanism, is that while request headers are arbitrarily controllable by users, environment variables are not, and it's probably a good idea not to conflate the two. > Another idea would be to create an abstract "capability" type, where a > page handler may always request such a value as a function argument. > State-access functions like header/environment variable reading could > require a value of this type as an argument, so that a page handler > could call other functions without giving them direct access to touch > the request/response context. So, I suppose what's not totally clear to me is why this isn't just the reader monad? Cheers, Edward _______________________________________________ Ur mailing list [email protected] http://www.impredicative.com/cgi-bin/mailman/listinfo/ur
