- tbnl-devel@lists.common-lisp.net - mailman3.common-lisp.net

Re: [hunchentoot-devel] Hunchentootin in the quicklisp repository?
by Zach Beane 11 Jun '11

11 Jun '11

Paul Harper <pauljharper(a)gmail.com> writes: > Thanks guys > it does seem to be there.. Thing is I was trying system-apropos with > "hunchentoot", also with "http" and got nothing. > Of course on windows I get the following messages (when trying to download > cl+ssl) and it seems I must download a libssl32.dll from 'shining light' .. Is > this the recommended way to go? (ql:system-apropos "hunchentoot") should return several items - maybe you had a typo? If you don't want SSL support, you can do this before loading Hunchentoot: (pushnew :hunchentoot-no-ssl *features*) Zach

1 0

Re: [hunchentoot-devel] Hunchentootin in the quicklisp repository?
by Edi Weitz 11 Jun '11

11 Jun '11

Hi, Please send questions related to Hunchentoot to the mailing list - see Cc. As to your question, to my knowledge Hunchentoot is already installable via Quicklisp. Cheers, Edi. On Sat, Jun 11, 2011 at 9:51 AM, Paul Harper <pauljharper(a)gmail.com> wrote: > Hi Edi > Am just getting going in lisp and busy checking out your Hunchentoot > webserver. Do you have any plans to add it to quicklisp repository? or do i > just use quicklisp to download the required libraries? > regards > Paul Harper

2 1

[hunchentoot-devel] Fwd: Intermittent problem with codequarterly website (chunked coding glitch?)
by Peter Seibel 10 Jun '11

10 Jun '11

I have no particular reason to believe Hunchentoot is at fault here but I figured I'd ask in case anyone had seen anything like this. The codequarterly.com website is being served by Apache proxying to Hunchentoot (via ProxyPass and ProxyPassReverse directives in the Apache config) and this user reports occasionally getting back some hinky chunked-coded responses. Any ideas of the top of anyone's head? -Peter ---------- Forwarded message ---------- From: Thomas (AWS), Chris <ccthomas(a)amazon.com> Date: Thu, Jun 9, 2011 at 6:14 PM Subject: Intermittent problem with codequarterly website (chunked coding glitch?) To: "editor(a)codequarterly.com" <editor(a)codequarterly.com> Greetings, This may not be the appropriate place to report this issue, but I couldn't find any technical contact information on your website. Feel free to forward as necessary. Intermittently (maybe 10-20% of the time), when trying to view pages on the codequarterly website, my browser is displaying what appears to be the text of the raw HTML of the page, instead of the rendered page. When I look closer, I see that the text begins with a hexadecimal number (e.g, '1FED'), followed by the usual HTML <DOCTYPE.... Header. I reproduced the problem with curl & took a packet trace (output at end of email), to better see what is going on: % curl -v http://www.codequarterly.com/2011/rich-hickey/ It shows that the response is coming back with chunked coding, but there are two hexadecimal numbers preceding the actual HTML content, instead of just the single number that one would expect from a chunked-coded response. The remainder of the body shows additional "extra" chunk length prefixes. It is almost as if the HTTP server was sending the response body through two passes of chunked encoding. Anyway, you might want to look into how your website software is set up that might be causing this, or perhaps whether there's a proxy that is inappropriately adding its own chunked coding to the response as it passes through. Best Regards, Chris Thomas -- request -- GET /2011/rich-hickey/ HTTP/1.1 User-Agent: curl/7.18.1 (i686-pc-linux-gnu) libcurl/7.18.1 OpenSSL/0.9.8b zlib/1.2.3 Host: www.codequarterly.com Accept: */* -- response -- HTTP/1.1 200 OK Date: Fri, 10 Jun 2011 00:51:12 GMT Transfer-Encoding: chunked Content-Type: text/plain 1f3e 1FE4<!DOCTYPE html> <HTML lang='en'> <HEAD> <META http-equiv='content-type' content='text/html; charset=UTF-8'> <TITLE>Code Quarterly</TITLE> .... -- Peter Seibel http://www.codequarterly.com/

2 1

[hunchentoot-devel] Hunchentoot support for ECL (implementation link)
by Olivier Dumont 09 Jun '11

09 Jun '11

Hi, the attached patch adds the link to the ECL implementation site. best regards, Olivier

1 0

[hunchentoot-devel] "start" does not return the acceptor
by Nic M 05 Jun '11

05 Jun '11

I am running on on SBCL 1.0.48 on Mac OS X installed through macports. This installation still hangs on 'start' as in single-threaded Lisp. Any suggestions on how to resolve this issue? -Nic On Wed, May 25, 2011 at 11:29 AM, Matus Kmit <simply.nitaai at gmail.com <http://lists.common-lisp.net/cgi-bin/mailman/listinfo/tbnl-devel>> wrote: >* i installed hunchentoot in clisp via quickload. it seems working well*>* except for the following:*>**>* The function "start" does not return the acceptor. It creates own, so*>* that the http-server works but it keeps on hanging on the command and*>* does not return to REPL so that i have to break manually.* You are running single threaded. If you want to run Hunchentoot in the background, you need a multi-threaded Lisp (CCL and SBCL work fine). -Hans

2 1

[hunchentoot-devel] slime foreground buffer for hunchentoot
by Mark H. David 25 May '11

25 May '11

I'm interested in having the ability to break, trace, etc., all the functions running in Hunchentoot. Is there any trick for this? I'd really like to ideally have a SLIME REPL buffer dedicated to it. Has anyone accomplished such a thing? I know Hunchentoot is not running in my main REPL thread. I'm assuming it's just running in one other thread, or mainly in one other thread, making this seem manageable. I'm mostly using CCL and SBCL for devel currently. Thanks, Mark

3 5

[hunchentoot-devel] "start" does not return the acceptor
by Matus Kmit 25 May '11

25 May '11

Hi i installed hunchentoot in clisp via quickload. it seems working well except for the following: The function "start" does not return the acceptor. It creates own, so that the http-server works but it keeps on hanging on the command and does not return to REPL so that i have to break manually. Any help would be appreciated Matus

2 2

Re: [hunchentoot-devel] static files in hunchtentoot 1.1.1
by Edi Weitz 25 May '11

25 May '11

Hi Mark, The URL needs to look like "/exp/...something", i.e. you need a slash after "exp" so that the browser knows how to interpret your GIF URLs. If you write src="foo.gif", the image is looked up relative to the "current directory". So, if the page you're looking at has "/exp/" in it, "exp" is the current directory. But if it only has "/exp" in it (no slash at the end), the current directory is the root directory. If you don't want to change your base URL, you can either use a different relative URL for your images like src="exp/foo.gif" or you can use an absolute URL like src "/exp/foo.gif". This is the way HTML works and it's obviously modeled after similar concepts like the Unix file system. If you don't get the image you're expecting to see, just look at what the browser is actually trying to retrieve from the server. In your original example I bet it tried to retrieve "http://127.0.0.1/leaf.gif" and not "http://127.0.0.1/exp/leaf.gif" as you expected. HTH, Edi. On Tue, May 24, 2011 at 4:23 PM, Mark H. David <mhd(a)yv.org> wrote: > Sorry, Edi, I'm just really lost. Could I ask you to clarify: > > Is your sentence saying what should be done to fix things, or what is wrong currently? > > And, which URL does your sentence refer to, the url-prefix arg to create-folder-..., or the example URL I gave (http://127.0.0.1:1234/exp?default-categorizer*)? > > And, while we're at it, I'm not that sure which direction is "behind"? Does "exp" have a slash behind it in the following string? "/exp" > > I've various things based on various interpretations, but I feel I'm thrashing. :( > > Thanks, > > Mark > > > ----- Original message ----- > From: "Edi Weitz" <edi(a)weitz.de> > To: "General interest list for Hunchentoot and CL-WEBDAV" <tbnl-devel(a)common-lisp.net> > Date: Tue, 24 May 2011 08:29:09 +0200 > Subject: Re: [hunchentoot-devel] static files in hunchtentoot 1.1.1 > > There's no slash behind "exp" in your URL. > > Edi. > > On Tue, May 24, 2011 at 7:49 AM, Mark H. David <mhd(a)yv.org> wrote: >> I cannot figure out how to serve static files (e.g., blah.gif) in Hunchentoot 1.1.1. >> >> I do >> >> (hunchentoot:create-folder-dispatcher-and-handler "/exp/" "c:\\hunchentoot\\") >> >> and then have a URL >> >> http://127.0.0.1:1234/exp?default-categorizer* >> >> that generates lots of >> >> <img src="leaf.gif"> >> >> and the like. The file "leaf.gif" is in the directory "c:\hunchentoot". >> >> However, the GIF file is not being served. I get the standard substitution image. >> >> What's the solution? >> >> Thanks, >> >> Mark >> >> _______________________________________________ >> tbnl-devel site list >> tbnl-devel(a)common-lisp.net >> http://common-lisp.net/mailman/listinfo/tbnl-devel >> >> > > _______________________________________________ > tbnl-devel site list > tbnl-devel(a)common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > >

1 0

[hunchentoot-devel] Output a XML file as a Response
by Colin 24 May '11

24 May '11

I want to get a xml response to browser, for example: I have a xml string such as: <person> <name>nick</name> <age>20</age> </person> and I have a request such as: http://localhost:8080/person it will output the xml to browser. Please give me some prompts. Thanks.

1 1

[hunchentoot-devel] static files in hunchtentoot 1.1.1
by Mark H. David 24 May '11

24 May '11

I cannot figure out how to serve static files (e.g., blah.gif) in Hunchentoot 1.1.1. I do (hunchentoot:create-folder-dispatcher-and-handler "/exp/" "c:\\hunchentoot\\") and then have a URL http://127.0.0.1:1234/exp?default-categorizer* that generates lots of <img src="leaf.gif"> and the like. The file "leaf.gif" is in the directory "c:\hunchentoot". However, the GIF file is not being served. I get the standard substitution image. What's the solution? Thanks, Mark

2 1