[Ur] Patch for Basis.clientIP

[Sergey Mironov]

2014-09-23 21:58 GMT+04:00 Adam Chlipala <adamc at csail.mit.edu>:
> On 09/23/2014 04:33 AM, Sergey Mironov wrote:
>>
>> Hi! Please, consider applying the patch for getting the IP-address of a
>> client.
>
>
> The basic functionality seems reasonable, but I have two misgivings about
> this patch:
>
> 1) Allowing all [transaction] code to read the client IP address by default
> bothers the capability-system nerd in me.  This kind of functionality seems
> roughly comparable to reading request headers, which currently works with a
> configurable whitelist of headers that may be read.  Most applications will
> rule out reading of most headers.
>
> 2) The compiler and runtime system include a plugin system for application
> protocols.  Of the 4 plugins that come with the compiler, I believe this
> patch will only work correctly for 1 of them, 'http'.  For at least one of
> them, 'fastcgi', I think the new operation will even always return
> localhost, rather than signaling a runtime error!  The parameter name 'sock'
> for uw_request() is actually quite misleading, as the parameter is not
> guaranteed to be a socket handle, even if it's greater than -1; it's treated
> like a polymorphically typed parameter, which only needs to be compatible
> with the 'send' parameter.  (Sorry about that grossness. :\)

I accept your notice! Basis.clientIP function is really a nonsense for
non-http backends. And yes,  non-http backends may lack access to the
client's IP address at all (I may imagine there may be an apache
plugin for setting HTTP header containing this information). From the
other hand, it is sad that programmer can't touch  transport level
even by using methods labeled 'unsafe'. I would have written an
FFI-module If I only could access the socket to pass to [getpeername].

Here is another possible scenario I am thinking about: we may store
backend-specific file handle into uw_context (maybe under [void*] type
for safety) and provide users with a C function like [int
uw_handle(uw_context *ctx)] returning this handle. This would make it
possible to move the responsibility to FFIs and allow me to write one
to do the job. Basis API will stay unchanged this way. What do you
think?