Hi, I wanted to setup really simple http server, found Network.CGI.Compat.pwrapper and decided it suits my needs. Code: module Main where import Network.CGI import Text.XHtml import Network doit vars = do return (body (toHtml (show vars))) main = withSocketsDo (pwrapper (PortNumber 7777) doit) Pointng any browser to http://127.0.0.1:7777 does not render the page. It seems the response headers are broken. How do I report this bug (trac? something else?). We might want to either fix it, or just get rid of it, as nobody seems to notice the problem :) $ ghc --version The Glorious Glasgow Haskell Compilation System, version 6.6 Tested under WinXP and MacOSX 10.4.9. Another question is: how do I do equivalent functionality without pwrapper? -- Gracjan
On Feb 12, 2007, at 14:22 , Gracjan Polak wrote:
I wanted to setup really simple http server, found Network.CGI.Compat.pwrapper and decided it suits my needs. Code:
module Main where import Network.CGI import Text.XHtml import Network
doit vars = do return (body (toHtml (show vars)))
main = withSocketsDo (pwrapper (PortNumber 7777) doit)
Pointng any browser to http://127.0.0.1:7777 does not render the page. It seems the response headers are broken.
How do I report this bug (trac? something else?).
We might want to either fix it, or just get rid of it, as nobody seems to notice the problem :)
$ ghc --version The Glorious Glasgow Haskell Compilation System, version 6.6
Tested under WinXP and MacOSX 10.4.9.
Hi Gracjan, pwrapper is not an HTTP server, though the Haddock comment can make you think so. pwrapper allows you to talk *CGI* over a TCP port, but I have no idea why anyone would like to do that. The functions in the Network.CGI.Compat module are deprecated, and shouldn't be used in new code. Even though I'm the maintainer of the cgi package, I don't really know what those functions could ever be useful for, and I've never seen any code which uses them. In fact, I've now removed the Network.CGI.Compat module and uploaded cgi-3001.0.0 to Hackage.
Another question is: how do I do equivalent functionality without pwrapper?
You can roll you own web server if you want something very simple. If you don't want to do that, there is a version of Simon Marlow's Haskell Web Server with CGI support [1]. You could also get the original HWS [2] and merge it with your program. You might also be interested In HAppS [3]. /Björn [1] http://www.cs.chalmers.se/~bringert/darcs/hws-cgi/ [2] http://darcs.haskell.org/hws/ [3] http://happs.org/
Bjorn Bringert wrote:
pwrapper is not an HTTP server, though the Haddock comment can make you think so. pwrapper allows you to talk *CGI* over a TCP port, but I have no idea why anyone would like to do that.
Here is a scenerio. I want a basic web application: someone makes a request, and my program computes a response. * For one reason or another, I settle with CGI. * The program is huge and slow to load. (Let's say it statically links in the whole GHC API and therefore is basically GHC itself. :) ) It would suck to re-load this program at every request. * Or, the program performs work that requires more file-system privilege than the admin of the web server grants. You know, a good admin sets up a web server and all CGI scripts to run with nobody's privilege. * Or, nevermind performance or privilege. I am a cheapo, and I use a cheapo hosting provider, which only provides me with 3MB of storage. My program weighs 17MB (recall that it links in the whole GHC :) ). Here is a solution. The program runs as a daemon and never quits; it can run somewhere with sufficient privilege and storage. It talks CGI over TCP. At the web server, which is super-slow, super-paranoid, and super-cheapo, the CGI script is a lightweight C program that redirects everything over TCP to my daemon. (Here is a counter-solution. The program still runs as a daemon somewhere, but it talks my own protocol over TCP. The CGI script is a lightweight C program that parses CGI into my own protocol. Besides having to design my own protocol carefully, here is a problem: C is a great language for writing parsers that are incomplete, inconsistent, and insecure. :) )
On Feb 12, 2007, at 23:27 , Albert Y. C. Lai wrote:
Bjorn Bringert wrote:
pwrapper is not an HTTP server, though the Haddock comment can make you think so. pwrapper allows you to talk *CGI* over a TCP port, but I have no idea why anyone would like to do that.
Here is a scenerio. I want a basic web application: someone makes a request, and my program computes a response.
* For one reason or another, I settle with CGI.
* The program is huge and slow to load. (Let's say it statically links in the whole GHC API and therefore is basically GHC itself. :) ) It would suck to re-load this program at every request.
* Or, the program performs work that requires more file-system privilege than the admin of the web server grants. You know, a good admin sets up a web server and all CGI scripts to run with nobody's privilege.
* Or, nevermind performance or privilege. I am a cheapo, and I use a cheapo hosting provider, which only provides me with 3MB of storage. My program weighs 17MB (recall that it links in the whole GHC :) ).
Here is a solution. The program runs as a daemon and never quits; it can run somewhere with sufficient privilege and storage. It talks CGI over TCP. At the web server, which is super-slow, super- paranoid, and super-cheapo, the CGI script is a lightweight C program that redirects everything over TCP to my daemon.
(Here is a counter-solution. The program still runs as a daemon somewhere, but it talks my own protocol over TCP. The CGI script is a lightweight C program that parses CGI into my own protocol. Besides having to design my own protocol carefully, here is a problem: C is a great language for writing parsers that are incomplete, inconsistent, and insecure. :) )
OK, that sounds reasonable, but I think that there are better solutions for those problems. Besides, it's niche stuff that I don't think belongs in the main CGI package. If anything wants it, it's easy to implement. * If you have slow start-up, you can use FastCGI instead of CGI. There is already a Haskell library for that. * If the program needs additional privileges, you can use an external FastCGI program which is started independently of the server. * If you have cheapo hosting, at least Apache mod_fastcgi allows you to run your FastCGI app on a different machine. Another solution would be mod_rewrite + mod_proxy. But if you have another server where you can run your application, why not put your web server there instead of using cheapo hosting? /Björn
On Feb 12, 2007, at 23:27 , Albert Y. C. Lai wrote:
Bjorn Bringert wrote:
pwrapper is not an HTTP server, though the Haddock comment can make you think so. pwrapper allows you to talk *CGI* over a TCP port, but I have no idea why anyone would like to do that.
Here is a scenerio. I want a basic web application: someone makes a request, and my program computes a response.
* For one reason or another, I settle with CGI.
* The program is huge and slow to load. (Let's say it statically links in the whole GHC API and therefore is basically GHC itself. :) ) It would suck to re-load this program at every request.
By the way, here's an example application which does just that using FastCGI: http://csmisc14.cs.chalmers.se/~bjorn/dynhs/examples/wiki/ wiki.hs It uses a dynamically started FastCGI application, which means that the web server starts up new processes when needed and keeps a bunch of them around to serve future requests.
...
/Björn
Hello Albert, Tuesday, February 13, 2007, 1:27:29 AM, you wrote:
* Or, nevermind performance or privilege. I am a cheapo, and I use a cheapo hosting provider, which only provides me with 3MB of storage. My program weighs 17MB (recall that it links in the whole GHC :) ).
may be hugs or yhc/nhc can provide you with cheap solution? hugs interpreter should fit into this storage together with libraries you need -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
Bjorn Bringert
Another question is: how do I do equivalent functionality without pwrapper?
You can roll you own web server if you want something very simple. If you don't want to do that, there is a version of Simon Marlow's Haskell Web Server with CGI support [1]. You could also get the original HWS [2] and merge it with your program. You might also be interested In HAppS [3].
Haskell Web Server seems to be the closest match. I don't want fully functional web server. I need more low level thing, as I need to set this up as a testing environment for some other (browser like) application. So I need a way to trigger (atrificial) errors, like protocol errors, garbage and broken connections. Thanks for the response. Is there a description what is a *CGI* protocol? -- Gracjan
On Feb 13, 2007, at 9:14 , Gracjan Polak wrote:
Bjorn Bringert
writes: Another question is: how do I do equivalent functionality without pwrapper?
You can roll you own web server if you want something very simple. If you don't want to do that, there is a version of Simon Marlow's Haskell Web Server with CGI support [1]. You could also get the original HWS [2] and merge it with your program. You might also be interested In HAppS [3].
Haskell Web Server seems to be the closest match. I don't want fully functional web server. I need more low level thing, as I need to set this up as a testing environment for some other (browser like) application. So I need a way to trigger (atrificial) errors, like protocol errors, garbage and broken connections.
Thanks for the response.
Is there a description what is a *CGI* protocol?
Here you go: http://hoohoo.ncsa.uiuc.edu/cgi/interface.html /Björn
Bjorn Bringert
Is there a description what is a *CGI* protocol?
Here you go: http://hoohoo.ncsa.uiuc.edu/cgi/interface.html
I should be more clear: what kind of data does pwrapper expect? Somewhere in the middle it needs two handles: one to write and one to read which seem to be equivalent to stdin/stdout. But what about environment? How is it transfered, as someone ale pointed out pwrapper runs on different machine? -- Gracjan
Gracjan Polak wrote:
Bjorn Bringert
writes: Is there a description what is a *CGI* protocol? Here you go: http://hoohoo.ncsa.uiuc.edu/cgi/interface.html
I should be more clear: what kind of data does pwrapper expect? Somewhere in the middle it needs two handles: one to write and one to read which seem to be equivalent to stdin/stdout. But what about environment? How is it transfered, as someone ale pointed out pwrapper runs on different machine?
I think your best bet is to read the code, it's not many lines. IIRC, pwrapper takes the environment variables from the local environment, which is rather useless. If you want a protocol for talking CGI over a socket, FastCGI does just that. /Björn
participants (5)
-
Albert Y. C. Lai -
Bjorn Bringert -
Björn Bringert
-
Bulat Ziganshin -
Gracjan Polak