From jeffreydbyrd at gmail.com Wed Jun 6 15:48:52 2012 From: jeffreydbyrd at gmail.com (Jeff Byrd) Date: Wed, 6 Jun 2012 11:48:52 -0400 Subject: [hunchentoot-devel] Running webserver on remote machine Message-ID: Hi everyone, This is my first attempt at a webapp, and first time posting to the mailing list. I have a question about starting a server on a remote machine. I've been playing with Hunchentoot on my localhost, and it works great. Earlier it worked on my remote webspace also. But recently I've been playing with SBCL threading and Allegro (following thistutorial, which had me install all sorts of weird gigamonkey stuff) and now when I run the command (hunchentoot:start (make-instance 'hunchentoot:easy-acceptor :port 8080)) it says # and going to :8080/ doesn't display anything. I hit cntr-z to put it in the background and then $ lsof -i :8080 and I get COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME sbcl 11350 root 5u IPv4 1816786 0t0 TCP *:http-alt (LISTEN) I have a feeling it's something simple, like incorrect host variable or a separate thread being stopped, but I'm having a hard time finding answers on Google and related documentation. Any suggestions or information on what that above message means would be greatly appreciated. Thanks! Jeff -------------- next part -------------- An HTML attachment was scrubbed... URL: From hans.huebner at gmail.com Wed Jun 6 17:56:54 2012 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Wed, 6 Jun 2012 19:56:54 +0200 Subject: [hunchentoot-devel] Running webserver on remote machine In-Reply-To: References: Message-ID: Hi Jeff, I don't quite know what exactly the problem is. Did you install Hunchentoot with quicklisp (http://www.quicklisp.org/)? If not, please do so. Also, what do you mean when you write "going to :8080/ doesn't display anything"? Do you get an empty page? -Hans On Wed, Jun 6, 2012 at 5:48 PM, Jeff Byrd wrote: > Hi everyone, > > This is my first attempt at a webapp, and first time posting to the > mailing list. I have a question about starting a server on a remote > machine. I've been playing with Hunchentoot on my localhost, and it works > great. Earlier it worked on my remote webspace also. But recently I've been > playing with SBCL threading and Allegro (following thistutorial, which had me install all sorts of weird gigamonkey stuff) and now > when I run the command > > (hunchentoot:start (make-instance 'hunchentoot:easy-acceptor :port 8080)) > > it says > # > and going to :8080/ doesn't display anything. > I hit cntr-z to put it in the background and then > > $ lsof -i :8080 and I get > > COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME > sbcl 11350 root 5u IPv4 1816786 0t0 TCP *:http-alt (LISTEN) > > I have a feeling it's something simple, like incorrect host variable or a > separate thread being stopped, but I'm having a hard time finding answers > on Google and related documentation. Any suggestions or information on what > that above message means would be greatly appreciated. > > Thanks! > Jeff > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeffreydbyrd at gmail.com Wed Jun 6 19:22:46 2012 From: jeffreydbyrd at gmail.com (Jeff Byrd) Date: Wed, 6 Jun 2012 15:22:46 -0400 Subject: [hunchentoot-devel] Running webserver on remote machine In-Reply-To: References:

Message-ID: Hi Hans thanks for your reply, I do have Hunchentoot installed using quicklisp. And sorry for the ambiguity, I meant that I enter the server's address in my browser's address bar (in this case it would be ec2-184-72-143-0.compute-1.amazonaws.com:8080), it then hangs for a while, and eventually shows an error page saying "Opps, Google Chrome could not connect..." Some additional info: On my local host, after entering the hunchentoot:start command, the prompt hangs until I hit CNTL-C. But on the remote host, it brings me back to the REPL. I'm still able to enter commands while sbcl runs (which I've read is characteristic of threading). I think I'll do a bit more homework and try to print request logs (if any) to a file. Thanks, Jeff On Wed, Jun 6, 2012 at 1:56 PM, Hans H?bner wrote: > Hi Jeff, > > I don't quite know what exactly the problem is. Did you install > Hunchentoot with quicklisp (http://www.quicklisp.org/)? If not, please > do so. Also, what do you mean when you write "going to :8080/ > doesn't display anything"? Do you get an empty page? > > -Hans > > On Wed, Jun 6, 2012 at 5:48 PM, Jeff Byrd wrote: > >> Hi everyone, >> >> This is my first attempt at a webapp, and first time posting to the >> mailing list. I have a question about starting a server on a remote >> machine. I've been playing with Hunchentoot on my localhost, and it works >> great. Earlier it worked on my remote webspace also. But recently I've been >> playing with SBCL threading and Allegro (following thistutorial, which had me install all sorts of weird gigamonkey stuff) and now >> when I run the command >> >> (hunchentoot:start (make-instance 'hunchentoot:easy-acceptor :port 8080)) >> >> it says >> # >> and going to :8080/ doesn't display anything. >> I hit cntr-z to put it in the background and then >> >> $ lsof -i :8080 and I get >> >> COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME >> sbcl 11350 root 5u IPv4 1816786 0t0 TCP *:http-alt (LISTEN) >> >> I have a feeling it's something simple, like incorrect host variable or a >> separate thread being stopped, but I'm having a hard time finding answers >> on Google and related documentation. Any suggestions or information on what >> that above message means would be greatly appreciated. >> >> Thanks! >> Jeff >> >> _______________________________________________ >> tbnl-devel site list >> tbnl-devel at common-lisp.net >> http://common-lisp.net/mailman/listinfo/tbnl-devel >> > > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From xach at xach.com Wed Jun 6 19:26:30 2012 From: xach at xach.com (Zach Beane) Date: Wed, 06 Jun 2012 15:26:30 -0400 Subject: [hunchentoot-devel] Running webserver on remote machine In-Reply-To: (Jeff Byrd's message of "Wed, 6 Jun 2012 15:22:46 -0400") References:

Message-ID: <87k3zks0m1.fsf@aliengleams.portland.xach.com> Jeff Byrd writes: > Hi Hans thanks for your reply, > I do have Hunchentoot installed using quicklisp. And sorry for the ambiguity, I > meant that I enter the server's address in my browser's address bar (in this > case it would be?ec2-184-72-143-0.compute-1.amazonaws.com:8080), it then hangs > for a while, and eventually shows an error page saying "Opps, Google Chrome > could not connect..." > > Some additional info: > On my local host, after entering the hunchentoot:start command, ?the prompt > hangs until I hit CNTL-C. But on the remote host, it brings me back to the > REPL. I'm still able to enter commands while sbcl runs (which I've read is > characteristic of threading). I think I'll do a bit more homework and try to > print request logs (if any) to a file. This is a sign that SBCL does not have thread support. You should rebuild it with threads to try Hunchentoot. Zach From whalliburton at gmail.com Thu Jun 7 01:10:33 2012 From: whalliburton at gmail.com (William Halliburton) Date: Wed, 6 Jun 2012 18:10:33 -0700 Subject: [hunchentoot-devel] Running webserver on remote machine In-Reply-To: References:

Message-ID: Note that since this is an amazon EC2 instance you will have to have allowed access to the instance on the 8080 port. Since you said that it worked earlier on the same instance I'm just throwing this out there as a low possibility. On Wed, Jun 6, 2012 at 12:22 PM, Jeff Byrd wrote: > Hi Hans thanks for your reply, > I do have Hunchentoot installed using quicklisp. And sorry for the > ambiguity, I meant that I enter the server's address in my browser's > address bar (in this case it would be > ec2-184-72-143-0.compute-1.amazonaws.com:8080), it then hangs for a > while, and eventually shows an error page saying "Opps, Google Chrome could > not connect..." > > Some additional info: > On my local host, after entering the hunchentoot:start command, the > prompt hangs until I hit CNTL-C. But on the remote host, it brings me back > to the REPL. I'm still able to enter commands while sbcl runs (which I've > read is characteristic of threading). I think I'll do a bit more homework > and try to print request logs (if any) to a file. > > Thanks, > Jeff > > > > On Wed, Jun 6, 2012 at 1:56 PM, Hans H?bner wrote: > >> Hi Jeff, >> >> I don't quite know what exactly the problem is. Did you install >> Hunchentoot with quicklisp (http://www.quicklisp.org/)? If not, please >> do so. Also, what do you mean when you write "going to :8080/ >> doesn't display anything"? Do you get an empty page? >> >> -Hans >> >> On Wed, Jun 6, 2012 at 5:48 PM, Jeff Byrd wrote: >> >>> Hi everyone, >>> >>> This is my first attempt at a webapp, and first time posting to the >>> mailing list. I have a question about starting a server on a remote >>> machine. I've been playing with Hunchentoot on my localhost, and it works >>> great. Earlier it worked on my remote webspace also. But recently I've been >>> playing with SBCL threading and Allegro (following thistutorial, which had me install all sorts of weird gigamonkey stuff) and now >>> when I run the command >>> >>> (hunchentoot:start (make-instance 'hunchentoot:easy-acceptor :port 8080)) >>> >>> it says >>> # >>> and going to :8080/ doesn't display anything. >>> I hit cntr-z to put it in the background and then >>> >>> $ lsof -i :8080 and I get >>> >>> COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME >>> sbcl 11350 root 5u IPv4 1816786 0t0 TCP *:http-alt (LISTEN) >>> >>> I have a feeling it's something simple, like incorrect host variable or >>> a separate thread being stopped, but I'm having a hard time finding answers >>> on Google and related documentation. Any suggestions or information on what >>> that above message means would be greatly appreciated. >>> >>> Thanks! >>> Jeff >>> >>> _______________________________________________ >>> tbnl-devel site list >>> tbnl-devel at common-lisp.net >>> http://common-lisp.net/mailman/listinfo/tbnl-devel >>> >> >> >> _______________________________________________ >> tbnl-devel site list >> tbnl-devel at common-lisp.net >> http://common-lisp.net/mailman/listinfo/tbnl-devel >> > > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeffreydbyrd at gmail.com Thu Jun 7 02:15:51 2012 From: jeffreydbyrd at gmail.com (Jeff Byrd) Date: Wed, 6 Jun 2012 22:15:51 -0400 Subject: [hunchentoot-devel] Running webserver on remote machine In-Reply-To: References:

Message-ID: Hi guys, thanks for all the suggestions. I do believe threads are enabled (otherwise the start command wouldn't return right?). And I've tried running it on several arbitrary ports, but the behavior remains consistent. I'm having trouble figuring out how to see the request logs. All I know is that the connection is timing out (Chrome gives me the message "Error 118 (net::ERR_CONNECTION_TIMED_OUT): The operation timed out."). It runs great on my localhost though so you're probably right in that it's a port or a host issue. Can anyone point me to some good books or tutorials on how this works? On Wed, Jun 6, 2012 at 9:10 PM, William Halliburton wrote: > Note that since this is an amazon EC2 instance you will have to have > allowed access to the instance on the 8080 port. Since you said that it > worked earlier on the same instance I'm just throwing this out there as a > low possibility. > > > On Wed, Jun 6, 2012 at 12:22 PM, Jeff Byrd wrote: > >> Hi Hans thanks for your reply, >> I do have Hunchentoot installed using quicklisp. And sorry for the >> ambiguity, I meant that I enter the server's address in my browser's >> address bar (in this case it would be >> ec2-184-72-143-0.compute-1.amazonaws.com:8080), it then hangs for a >> while, and eventually shows an error page saying "Opps, Google Chrome could >> not connect..." >> >> Some additional info: >> On my local host, after entering the hunchentoot:start command, the >> prompt hangs until I hit CNTL-C. But on the remote host, it brings me back >> to the REPL. I'm still able to enter commands while sbcl runs (which I've >> read is characteristic of threading). I think I'll do a bit more homework >> and try to print request logs (if any) to a file. >> >> Thanks, >> Jeff >> >> >> >> On Wed, Jun 6, 2012 at 1:56 PM, Hans H?bner wrote: >> >>> Hi Jeff, >>> >>> I don't quite know what exactly the problem is. Did you install >>> Hunchentoot with quicklisp (http://www.quicklisp.org/)? If not, please >>> do so. Also, what do you mean when you write "going to :8080/ >>> doesn't display anything"? Do you get an empty page? >>> >>> -Hans >>> >>> On Wed, Jun 6, 2012 at 5:48 PM, Jeff Byrd wrote: >>> >>>> Hi everyone, >>>> >>>> This is my first attempt at a webapp, and first time posting to the >>>> mailing list. I have a question about starting a server on a remote >>>> machine. I've been playing with Hunchentoot on my localhost, and it works >>>> great. Earlier it worked on my remote webspace also. But recently I've been >>>> playing with SBCL threading and Allegro (following thistutorial, which had me install all sorts of weird gigamonkey stuff) and now >>>> when I run the command >>>> >>>> (hunchentoot:start (make-instance 'hunchentoot:easy-acceptor :port 8080)) >>>> >>>> it says >>>> # >>>> and going to :8080/ doesn't display anything. >>>> I hit cntr-z to put it in the background and then >>>> >>>> $ lsof -i :8080 and I get >>>> >>>> COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME >>>> sbcl 11350 root 5u IPv4 1816786 0t0 TCP *:http-alt (LISTEN) >>>> >>>> I have a feeling it's something simple, like incorrect host variable or >>>> a separate thread being stopped, but I'm having a hard time finding answers >>>> on Google and related documentation. Any suggestions or information on what >>>> that above message means would be greatly appreciated. >>>> >>>> Thanks! >>>> Jeff >>>> >>>> _______________________________________________ >>>> tbnl-devel site list >>>> tbnl-devel at common-lisp.net >>>> http://common-lisp.net/mailman/listinfo/tbnl-devel >>>> >>> >>> >>> _______________________________________________ >>> tbnl-devel site list >>> tbnl-devel at common-lisp.net >>> http://common-lisp.net/mailman/listinfo/tbnl-devel >>> >> >> >> _______________________________________________ >> tbnl-devel site list >> tbnl-devel at common-lisp.net >> http://common-lisp.net/mailman/listinfo/tbnl-devel >> > > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hans.huebner at gmail.com Thu Jun 7 07:37:22 2012 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Thu, 7 Jun 2012 09:37:22 +0200 Subject: [hunchentoot-devel] Running webserver on remote machine In-Reply-To: References:

Message-ID: Hi Jeff, I found this summary on how to configure EC2 security groups: http://cloud-computing.learningtree.com/2010/09/24/understanding-amazon-ec2-security-groups-and-firewalls/ Basically, you need to make port 8080 accessible from the outside. HTH, Hans On Thu, Jun 7, 2012 at 4:15 AM, Jeff Byrd wrote: > Hi guys, thanks for all the suggestions. I do believe threads are enabled > (otherwise the start command wouldn't return right?). And I've tried > running it on several arbitrary ports, but the behavior remains consistent. > I'm having trouble figuring out how to see the request logs. All I know is > that the connection is timing out > (Chrome gives me the message "Error 118 (net::ERR_CONNECTION_TIMED_OUT): > The operation timed out."). > It runs great on my localhost though so you're probably right in that it's > a port or a host issue. Can anyone point me to some good books or tutorials > on how this works? > > > On Wed, Jun 6, 2012 at 9:10 PM, William Halliburton < > whalliburton at gmail.com> wrote: > >> Note that since this is an amazon EC2 instance you will have to have >> allowed access to the instance on the 8080 port. Since you said that it >> worked earlier on the same instance I'm just throwing this out there as a >> low possibility. >> >> >> On Wed, Jun 6, 2012 at 12:22 PM, Jeff Byrd wrote: >> >>> Hi Hans thanks for your reply, >>> I do have Hunchentoot installed using quicklisp. And sorry for the >>> ambiguity, I meant that I enter the server's address in my browser's >>> address bar (in this case it would be >>> ec2-184-72-143-0.compute-1.amazonaws.com:8080), it then hangs for a >>> while, and eventually shows an error page saying "Opps, Google Chrome could >>> not connect..." >>> >>> Some additional info: >>> On my local host, after entering the hunchentoot:start command, the >>> prompt hangs until I hit CNTL-C. But on the remote host, it brings me back >>> to the REPL. I'm still able to enter commands while sbcl runs (which I've >>> read is characteristic of threading). I think I'll do a bit more homework >>> and try to print request logs (if any) to a file. >>> >>> Thanks, >>> Jeff >>> >>> >>> >>> On Wed, Jun 6, 2012 at 1:56 PM, Hans H?bner wrote: >>> >>>> Hi Jeff, >>>> >>>> I don't quite know what exactly the problem is. Did you install >>>> Hunchentoot with quicklisp (http://www.quicklisp.org/)? If not, >>>> please do so. Also, what do you mean when you write "going to >>>> :8080/ doesn't display anything"? Do you get an empty page? >>>> >>>> -Hans >>>> >>>> On Wed, Jun 6, 2012 at 5:48 PM, Jeff Byrd wrote: >>>> >>>>> Hi everyone, >>>>> >>>>> This is my first attempt at a webapp, and first time posting to the >>>>> mailing list. I have a question about starting a server on a remote >>>>> machine. I've been playing with Hunchentoot on my localhost, and it works >>>>> great. Earlier it worked on my remote webspace also. But recently I've been >>>>> playing with SBCL threading and Allegro (following thistutorial, which had me install all sorts of weird gigamonkey stuff) and now >>>>> when I run the command >>>>> >>>>> (hunchentoot:start (make-instance 'hunchentoot:easy-acceptor :port 8080)) >>>>> >>>>> it says >>>>> # >>>>> and going to :8080/ doesn't display anything. >>>>> I hit cntr-z to put it in the background and then >>>>> >>>>> $ lsof -i :8080 and I get >>>>> >>>>> COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME >>>>> sbcl 11350 root 5u IPv4 1816786 0t0 TCP *:http-alt >>>>> (LISTEN) >>>>> >>>>> I have a feeling it's something simple, like incorrect host variable >>>>> or a separate thread being stopped, but I'm having a hard time finding >>>>> answers on Google and related documentation. Any suggestions or information >>>>> on what that above message means would be greatly appreciated. >>>>> >>>>> Thanks! >>>>> Jeff >>>>> >>>>> _______________________________________________ >>>>> tbnl-devel site list >>>>> tbnl-devel at common-lisp.net >>>>> http://common-lisp.net/mailman/listinfo/tbnl-devel >>>>> >>>> >>>> >>>> _______________________________________________ >>>> tbnl-devel site list >>>> tbnl-devel at common-lisp.net >>>> http://common-lisp.net/mailman/listinfo/tbnl-devel >>>> >>> >>> >>> _______________________________________________ >>> tbnl-devel site list >>> tbnl-devel at common-lisp.net >>> http://common-lisp.net/mailman/listinfo/tbnl-devel >>> >> >> >> _______________________________________________ >> tbnl-devel site list >> tbnl-devel at common-lisp.net >> http://common-lisp.net/mailman/listinfo/tbnl-devel >> > > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeffreydbyrd at gmail.com Thu Jun 7 12:11:56 2012 From: jeffreydbyrd at gmail.com (Jeff Byrd) Date: Thu, 7 Jun 2012 08:11:56 -0400 Subject: [hunchentoot-devel] Running webserver on remote machine In-Reply-To: References:

Message-ID: Hi Hans, It turns out my server was configured so that only ports 80 and 3336 were open. Running it on port 80 works perfectly. Thanks for your help and being patient! Jeff On Thu, Jun 7, 2012 at 3:37 AM, Hans H?bner wrote: > Hi Jeff, > > I found this summary on how to configure EC2 security groups: > http://cloud-computing.learningtree.com/2010/09/24/understanding-amazon-ec2-security-groups-and-firewalls/ > > Basically, you need to make port 8080 accessible from the outside. > > HTH, > Hans > > > On Thu, Jun 7, 2012 at 4:15 AM, Jeff Byrd wrote: > >> Hi guys, thanks for all the suggestions. I do believe threads are enabled >> (otherwise the start command wouldn't return right?). And I've tried >> running it on several arbitrary ports, but the behavior remains consistent. >> I'm having trouble figuring out how to see the request logs. All I know is >> that the connection is timing out >> (Chrome gives me the message "Error 118 (net::ERR_CONNECTION_TIMED_OUT): >> The operation timed out."). >> It runs great on my localhost though so you're probably right in that >> it's a port or a host issue. Can anyone point me to some good books or >> tutorials on how this works? >> >> >> On Wed, Jun 6, 2012 at 9:10 PM, William Halliburton < >> whalliburton at gmail.com> wrote: >> >>> Note that since this is an amazon EC2 instance you will have to have >>> allowed access to the instance on the 8080 port. Since you said that it >>> worked earlier on the same instance I'm just throwing this out there as a >>> low possibility. >>> >>> >>> On Wed, Jun 6, 2012 at 12:22 PM, Jeff Byrd wrote: >>> >>>> Hi Hans thanks for your reply, >>>> I do have Hunchentoot installed using quicklisp. And sorry for the >>>> ambiguity, I meant that I enter the server's address in my browser's >>>> address bar (in this case it would be >>>> ec2-184-72-143-0.compute-1.amazonaws.com:8080), it then hangs for a >>>> while, and eventually shows an error page saying "Opps, Google Chrome could >>>> not connect..." >>>> >>>> Some additional info: >>>> On my local host, after entering the hunchentoot:start command, the >>>> prompt hangs until I hit CNTL-C. But on the remote host, it brings me back >>>> to the REPL. I'm still able to enter commands while sbcl runs (which I've >>>> read is characteristic of threading). I think I'll do a bit more homework >>>> and try to print request logs (if any) to a file. >>>> >>>> Thanks, >>>> Jeff >>>> >>>> >>>> >>>> On Wed, Jun 6, 2012 at 1:56 PM, Hans H?bner wrote: >>>> >>>>> Hi Jeff, >>>>> >>>>> I don't quite know what exactly the problem is. Did you install >>>>> Hunchentoot with quicklisp (http://www.quicklisp.org/)? If not, >>>>> please do so. Also, what do you mean when you write "going to >>>>> :8080/ doesn't display anything"? Do you get an empty page? >>>>> >>>>> -Hans >>>>> >>>>> On Wed, Jun 6, 2012 at 5:48 PM, Jeff Byrd wrote: >>>>> >>>>>> Hi everyone, >>>>>> >>>>>> This is my first attempt at a webapp, and first time posting to the >>>>>> mailing list. I have a question about starting a server on a remote >>>>>> machine. I've been playing with Hunchentoot on my localhost, and it works >>>>>> great. Earlier it worked on my remote webspace also. But recently I've been >>>>>> playing with SBCL threading and Allegro (following thistutorial, which had me install all sorts of weird gigamonkey stuff) and now >>>>>> when I run the command >>>>>> >>>>>> (hunchentoot:start (make-instance 'hunchentoot:easy-acceptor :port 8080)) >>>>>> >>>>>> it says >>>>>> # >>>>>> and going to :8080/ doesn't display anything. >>>>>> I hit cntr-z to put it in the background and then >>>>>> >>>>>> $ lsof -i :8080 and I get >>>>>> >>>>>> COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME >>>>>> sbcl 11350 root 5u IPv4 1816786 0t0 TCP *:http-alt >>>>>> (LISTEN) >>>>>> >>>>>> I have a feeling it's something simple, like incorrect host variable >>>>>> or a separate thread being stopped, but I'm having a hard time finding >>>>>> answers on Google and related documentation. Any suggestions or information >>>>>> on what that above message means would be greatly appreciated. >>>>>> >>>>>> Thanks! >>>>>> Jeff >>>>>> >>>>>> _______________________________________________ >>>>>> tbnl-devel site list >>>>>> tbnl-devel at common-lisp.net >>>>>> http://common-lisp.net/mailman/listinfo/tbnl-devel >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> tbnl-devel site list >>>>> tbnl-devel at common-lisp.net >>>>> http://common-lisp.net/mailman/listinfo/tbnl-devel >>>>> >>>> >>>> >>>> _______________________________________________ >>>> tbnl-devel site list >>>> tbnl-devel at common-lisp.net >>>> http://common-lisp.net/mailman/listinfo/tbnl-devel >>>> >>> >>> >>> _______________________________________________ >>> tbnl-devel site list >>> tbnl-devel at common-lisp.net >>> http://common-lisp.net/mailman/listinfo/tbnl-devel >>> >> >> >> _______________________________________________ >> tbnl-devel site list >> tbnl-devel at common-lisp.net >> http://common-lisp.net/mailman/listinfo/tbnl-devel >> > > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From orbisignis at msn.com Tue Jun 26 18:41:15 2012 From: orbisignis at msn.com (K B) Date: Tue, 26 Jun 2012 18:41:15 +0000 Subject: [hunchentoot-devel] MD5 array out of bounds Message-ID: Hi all, I'm currently implementing a website using Hunchentoot (which I gotta say is a top bit of work!) and have stumbled upon a problem whilst trying to use sessions. The symptom is that, when a call to 'start-session' is made I run into the error: "Error when creating REQUEST object: Array index 16 out of bounds for #(0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0)" Now, hunchentoot passes the client browser info string (not sure what is called, but here is an example "Opera/9.80 (Windows NT 6.1; WOW64; U; Edition United Kingdom Local; en) Presto/2.10.289 Version/12.00") to the hunchentoot:md5-hex function. The interesting thing here is that the example I just gave will give an error but if you access it from another browser (e.g. Maxthon), there is no error. The difference is in the length of the "client browser info string" that the browser passes - it is shorter. I have followed the problem to the 'finalize-md5-state' function in the md5 package, if this function is called with a string of 119 characters or less, everything is fine. However, call it with 120 characters or more and it will throw the aforementioned error. I have managed whittle the problem down to the following piece of code in the function definition of 'finalize-md5-state' in the md5 package: ;; Create new fully 0 padded block (loop for index of-type (integer 0 16) from 0 below 16 do (setf (aref block index) #x00000000))) If this is changed to: ;; Create new fully 0 padded block (loop for index from 0 below 16 do (setf (aref block index) #x00000000))) Then all is well, the function can be called with a string of more than 119 characters and start-session will work fine with browsers that choose to use long self identification strings. Now, I am not particularly sure why doing this solves the problem, I don't *think* it should matter (looks like a bug to me, its just optimisation code, right?) but I am certainly not well enough versed with lisp to be able to pass any judgment. In case this is an implementation thing, I am running Hunchentoot on Clozure on Debian Squeeze. Also, this error occurs with versions 1.3 and 1.5 of the md5 package (according to Cliki, 1.5 is the most recent release, and I cannot find a newer version). Thought I'd best post it to the Hunchentoot list, even though technically it is an MD5 problem, as I'm sure someone else using Hunchentoot will bump into this problem sooner or later (or maybe one of your sites is a victim to it - Opera is not that popular a browser!), plus, I'm having trouble finding out where to post it for the maintainer of MD5 to see it. Cheers, Kyle -------------- next part -------------- An HTML attachment was scrubbed... URL: From hans.huebner at gmail.com Wed Jun 27 09:46:59 2012 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Wed, 27 Jun 2012 11:46:59 +0200 Subject: [hunchentoot-devel] MD5 array out of bounds In-Reply-To: References: Message-ID: Hi Kyle, thank you for your bug report. This is a CCL bug and I have opened a bug in their bug tracking system for it (http://trac.clozure.com/ccl/ticket/990). Meanwhile, you may want to try an older CCL release or use another Lisp if the problem stops you from making progress. -Hans On Tue, Jun 26, 2012 at 8:41 PM, K B wrote: > Hi all, > > > I'm currently implementing a website using Hunchentoot (which I gotta say is > a top bit of work!) and have stumbled upon a problem whilst trying to use > sessions. The symptom is that, when a call to 'start-session' is made ?I run > into the error: > > > "Error when creating REQUEST object: Array index 16 out of bounds for #(0 0 > 0 0 0 0 0 0 0 0 0 0 0 0 0 0)" > > > Now, hunchentoot passes the client browser info string (not sure what is > called, ?but here is an example "Opera/9.80 (Windows NT 6.1; WOW64; U; > Edition United Kingdom Local; en) Presto/2.10.289 Version/12.00") to the > hunchentoot:md5-hex function. The interesting thing here is that the example > I just gave will give an error but if you access it from another browser > (e.g. Maxthon), there is no error. The difference is in the length of the > "client browser info string" that the browser passes - it is shorter. > > > I have followed the problem to the 'finalize-md5-state' function in the md5 > package, if this function is called with a string of 119 characters or less, > everything is fine. However, call it ?with 120 characters or more and it > will throw the aforementioned error. > > > I have managed whittle the problem down to the following piece of code in > the function definition of 'finalize-md5-state' in the md5 package: > > > ;; Create new fully 0 padded block > (loop for index of-type (integer 0 16) from 0 below 16 > do (setf (aref block index) #x00000000))) > > > If this is changed to: > > > ;; Create new fully 0 padded block > ? (loop for index from 0 below 16 > do (setf (aref block index) #x00000000))) > > > Then all is well, the function can be called with a string of more than 119 > characters and start-session will work fine with browsers that choose to use > long self identification strings. Now, I am not particularly sure why doing > this solves the problem, I don't *think* it should matter (looks like a bug > to me, its just optimisation code, right?) but I am certainly not well > enough versed with lisp to be able to pass any judgment. > > > In case this is an implementation thing, I am running Hunchentoot on Clozure > on Debian Squeeze. Also, this error occurs with versions 1.3 and 1.5 of the > md5 package (according to Cliki, 1.5 is the most recent release, and I > cannot find a newer version). > > > Thought I'd best post it to the Hunchentoot list, even though technically it > is an MD5 problem, as I'm sure someone else using Hunchentoot will bump into > this problem sooner or later (or maybe one of your sites is a victim to it - > Opera is not that popular a browser!), plus, I'm having trouble finding out > where to post it for the maintainer of MD5 to see it. > > > Cheers, > Kyle > > > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel From hans.huebner at gmail.com Wed Jun 27 14:01:29 2012 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Wed, 27 Jun 2012 16:01:29 +0200 Subject: [hunchentoot-devel] MD5 array out of bounds In-Reply-To: References:

Message-ID: On Wed, Jun 27, 2012 at 11:46 AM, Hans H?bner wrote: > thank you for your bug report. ?This is a CCL bug and I have opened a > bug in their bug tracking system for it > (http://trac.clozure.com/ccl/ticket/990). ?Meanwhile, you may want to > try an older CCL release or use another Lisp if the problem stops you > from making progress. This bug is indeed a CCL bug that has been fixed since release 1.8. Please go to your CCL directory, use "svn update" to pull the latest patches and use "ccl -e '(ccl:rebuild-ccl)'" to rebuild your Lisp. -Hans From stassats at gmail.com Wed Jun 27 14:17:40 2012 From: stassats at gmail.com (Stas Boukarev) Date: Wed, 27 Jun 2012 18:17:40 +0400 Subject: [hunchentoot-devel] MD5 array out of bounds In-Reply-To: ("Hans \=\?utf-8\?Q\?H\=C3\=BCbner\=22's\?\= message of "Wed, 27 Jun 2012 16:01:29 +0200") References:

Message-ID: <87k3ysdekb.fsf@gmail.com> Hans H?bner writes: > On Wed, Jun 27, 2012 at 11:46 AM, Hans H?bner wrote: >> thank you for your bug report. ?This is a CCL bug and I have opened a >> bug in their bug tracking system for it >> (http://trac.clozure.com/ccl/ticket/990). ?Meanwhile, you may want to >> try an older CCL release or use another Lisp if the problem stops you >> from making progress. > > This bug is indeed a CCL bug that has been fixed since release 1.8. > Please go to your CCL directory, use "svn update" to pull the latest > patches and use "ccl -e '(ccl:rebuild-ccl)'" to rebuild your Lisp. ccl -e '(ccl:rebuild-ccl :full t)' might be better. -- With best regards, Stas.