David Thompson <dthomps...@worcester.edu> skribis: > Mark H Weaver <m...@netris.org> writes: > >> l...@gnu.org (Ludovic Courtès) writes: >> >>> David Thompson <dthomps...@worcester.edu> skribis: >>> >>>> +(define (render-nar request store-item) >>>> + "Render archive of the store path corresponding to STORE-ITEM." >>>> + (let ((store-path (string-append %store-directory "/" store-item))) >>>> + ;; The ISO-8859-1 charset *must* be used otherwise HTTP clients will >>>> + ;; interpret the byte stream as UTF-8 and arbitrarily change invalid >>>> byte >>>> + ;; sequences. >>>> + (if (file-exists? store-path) >>>> + (values '((content-type . (application/x-nix-archive >>>> + (charset . "ISO-8859-1")))) >>>> + (lambda (port) >>>> + (write-file store-path port))) >>>> + (not-found request)))) >>> >>> This is OK for now, but I just realized that this will be blocking the >>> server for the duration of the whole transfer. Someone could DoS you by >>> substituting TeX Live. ;-) >>> >>> We’ll need a solution but it seems that it’ll be hard to avoid threads. >>> >>> Thoughts? >> >> I haven't looked closely, but how about using subprocesses instead of >> threads?
Sounds good. > That's along the lines of what I was thinking. One could spawn a bunch > of 'guix publish' processes on different ports and put a load balancer > in front of them. What about changing the ‘open’ method of the <server-impl> (as in tests/lint.scm) so that it forks upon socket opening? (That could also be the moment where we’d drop privileges.) > I think that this problem, if it is to be solved with more Scheme code, > is an issue to address in Guile core by changing the http server > implementation. Once we have a sufficiently different and valuable server implementation, we could turn it into a (web server xxx) module. I think there’s value in keeping the simple/simplistic (web server http) too. Ludo’.
