[teepeedee2-devel] More TPD2 patches.

[John Fremlin]

Hi Vladimir,

I'm about to knock up a TODO list for tpd2. I am encouraged that you now
understand the sendbuf stuff -- I would like to rewrite it using
Stelian's proper buffer pinning (if it is finished), and maybe a better
representation using an array instead of list head and tails. . .

Vladimir Sedach <vsedach at gmail.com> writes:
[...]
>>> +(defvar request-remote-ip*)
>>> +(defvar request-remote-port*) ;; TODO
>>> +(defvar request-headers*) ;; TODO
>>> +(defvar request-method*)
>>> +(defvar request-uri*)
>>> +(defvar request-path*)
>>> +(defvar request-raw-post-data*) ;; (file upload) TODO
>>> +(defvar request-parameters*)
>>
>> Why do these things have only one earmuff?
>
> That's a convention I borrowed from Hunchentoot 1.0.

Looking at the Hunchentoot mechanism, I think that it does something like
this

(defun remote-addr* (&optional (request *request*))
  "Returns the address the current request originated from."
  (remote-addr request))

So that it has just one special variable (i.e. *request*) and the star
is on the function is to indicate that it by default accesses that *request*.

This seems like quite a sensible approach, as it avoids an explosion of
special variables.

>> I kind of like this idea, and I guess I will test it out on my benchmark
>> game to see if it is feasible. Have you done any benchmarks yourself?
>
> Nope, still haven't gotten my code to run. However, I'm not sure this
> (dynamically scoped variables) actually works. Is there any point
> during the request dispatching where it can happen that the current
> continuation is saved and the thread begins servicing another request?
> If that's so then obviously this approach doesn't work.

I think that now the request dispatching waits until all the HTTP
request headers have been sent before doing anything at all (before, it
could partially handle one header line at a time but cl-cont made that
very slow).

Then if there is no request body (i.e. not a POST) then it dispatches
straightaway. Otherwise it might do a context switches (I think).

Note the channel page handler for an example which does not return
immediately and so would use the hated let-preserving-specials :-)

[...]
>> I want the path and parameters to be passed to this function.
>
> *If* the dynamic vars work, then you can get at them via request-path*
> and request-parameters*. Otherwise, yeah, this is going to need the
> request details as an argument.

O sorry, that was stupid of me.

>
>>> +                                          ("x-forwarded-for" ;; FIXME
>>> +                                           (setf request-remote-ip*
>>>                                                   (match-x-forwarded-for value)))))))
>>
>> Why the FIXME?
>
> I'm not sure having x-forwarded-for clobber the request-remote-ip
> value is the right thing to do.

Yes, I wanted to make that a configuration option somehow. But as I
always use tpd2 behind another server, I haven't done it.

I guess that should be a configuration option on the dispatcher (not
sure really).

[...]
> What's the difference between typing +action-page-name+ and
> "/*action*"? The URI is what needs to be the same. Having an alias for
> it just makes the code harder to grep.

I was a bit worried about having the earmuffs and it is easier to change
it in one place.

Otherwise I agree that maybe it is the wrong side of the balance.