From semion.ababo at gmail.com Wed Sep 1 10:40:15 2010 From: semion.ababo at gmail.com (Semion Prihodko) Date: Wed, 1 Sep 2010 13:40:15 +0300 Subject: [hunchentoot-devel] Chained SSL-certificates support Message-ID: Hi guys, I built a website which runs on Hunchentoot. Now it's time to buy ssl-certificate. When I downloaded QuickSSL Trial cert I found out that not all the browsers accept it. After a little research I found out that there is another certificate must be installed. This means it's a "chain root certificate", not a "single root". But it seems Hunchentoot has no capability to work with chained certificates. CL+SSL has an interesting function called USE-CERTIFICATE-CHAIN-FILE, but when I use it before creation of my ssl-acceptor the second doesn't respond to browsers. What can I do in order to fix this issue? Thanks in advance. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hans.huebner at gmail.com Wed Sep 1 11:50:09 2010 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Wed, 1 Sep 2010 13:50:09 +0200 Subject: [hunchentoot-devel] Chained SSL-certificates support In-Reply-To: References: Message-ID: Semion, can you please supply us with a minimal test case and pointers to the certificate files that you have tried? Thanks, Hans On Wed, Sep 1, 2010 at 12:40, Semion Prihodko wrote: > Hi guys, > I built a website which runs on Hunchentoot. Now it's time to buy > ssl-certificate. When I downloaded QuickSSL Trial cert I found out that not > all the browsers accept it. After a little research I found out that there > is another certificate must be installed. This means it's a "chain root > certificate", not a "single root". But it seems Hunchentoot has no > capability to work with chained certificates. CL+SSL has an interesting > function called?USE-CERTIFICATE-CHAIN-FILE, but when I use it before > creation of my ssl-acceptor the second doesn't respond to browsers. What can > I do in order to fix this issue? Thanks in advance. > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > From semion.ababo at gmail.com Wed Sep 1 11:58:54 2010 From: semion.ababo at gmail.com (Semion Prihodko) Date: Wed, 1 Sep 2010 14:58:54 +0300 Subject: [hunchentoot-devel] Chained SSL-certificates support In-Reply-To: References: Message-ID: The code is very simple. ;; begin of new code (cl+ssl:reload) (cl+ssl:use-certificate-chain-file "mysite.cer") ; my site (cl+ssl:use-certificate-chain-file "geotrust.cer") ; intermediate (cl+ssl:use-certificate-chain-file "geotrust+.cer") ; root ;; end of new code (make-instance 'ssl-acceptor :ssl-certificate-file (car ssl-security) :ssl-privatekey-file (cdr ssl-security) :port (get-config-value :website-port)) 2010/9/1 Hans H?bner > Semion, > > can you please supply us with a minimal test case and pointers to the > certificate files that you have tried? > > Thanks, > Hans > > On Wed, Sep 1, 2010 at 12:40, Semion Prihodko > wrote: > > Hi guys, > > I built a website which runs on Hunchentoot. Now it's time to buy > > ssl-certificate. When I downloaded QuickSSL Trial cert I found out that > not > > all the browsers accept it. After a little research I found out that > there > > is another certificate must be installed. This means it's a "chain root > > certificate", not a "single root". But it seems Hunchentoot has no > > capability to work with chained certificates. CL+SSL has an interesting > > function called USE-CERTIFICATE-CHAIN-FILE, but when I use it before > > creation of my ssl-acceptor the second doesn't respond to browsers. What > can > > I do in order to fix this issue? Thanks in advance. > > _______________________________________________ > > 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 semion.ababo at gmail.com Wed Sep 1 12:01:43 2010 From: semion.ababo at gmail.com (Semion Prihodko) Date: Wed, 1 Sep 2010 15:01:43 +0300 Subject: [hunchentoot-devel] Chained SSL-certificates support In-Reply-To: References: Message-ID: forgot to attach certificates. here. 2010/9/1 Semion Prihodko > The code is very simple. > > ;; begin of new code > (cl+ssl:reload) > (cl+ssl:use-certificate-chain-file "mysite.cer") ; my site > (cl+ssl:use-certificate-chain-file "geotrust.cer") ; intermediate > (cl+ssl:use-certificate-chain-file "geotrust+.cer") ; root > ;; end of new code > > (make-instance 'ssl-acceptor > :ssl-certificate-file (car ssl-security) > :ssl-privatekey-file (cdr ssl-security) > :port (get-config-value :website-port)) > > > 2010/9/1 Hans H?bner > > Semion, >> >> can you please supply us with a minimal test case and pointers to the >> certificate files that you have tried? >> >> Thanks, >> Hans >> >> On Wed, Sep 1, 2010 at 12:40, Semion Prihodko >> wrote: >> > Hi guys, >> > I built a website which runs on Hunchentoot. Now it's time to buy >> > ssl-certificate. When I downloaded QuickSSL Trial cert I found out that >> not >> > all the browsers accept it. After a little research I found out that >> there >> > is another certificate must be installed. This means it's a "chain root >> > certificate", not a "single root". But it seems Hunchentoot has no >> > capability to work with chained certificates. CL+SSL has an interesting >> > function called USE-CERTIFICATE-CHAIN-FILE, but when I use it before >> > creation of my ssl-acceptor the second doesn't respond to browsers. What >> can >> > I do in order to fix this issue? Thanks in advance. >> > _______________________________________________ >> > 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: mysite.cer Type: application/octet-stream Size: 1828 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: geotrust.cer Type: application/octet-stream Size: 1462 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: geotrust+.cer Type: application/octet-stream Size: 1236 bytes Desc: not available URL: From hans.huebner at gmail.com Wed Sep 1 12:03:07 2010 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Wed, 1 Sep 2010 14:03:07 +0200 Subject: [hunchentoot-devel] Chained SSL-certificates support In-Reply-To: References: Message-ID: Please post links to the certificates, too. Thanks. On Wed, Sep 1, 2010 at 13:58, Semion Prihodko wrote: > The code is very simple. > ;; begin of new code > (cl+ssl:reload) > (cl+ssl:use-certificate-chain-file "mysite.cer") ; my site > (cl+ssl:use-certificate-chain-file "geotrust.cer") ; intermediate > (cl+ssl:use-certificate-chain-file "geotrust+.cer") ; root > ;; end of new code > (make-instance 'ssl-acceptor > ?? ? ? ? ? ? ? ? ? ? ? :ssl-certificate-file (car ssl-security) > ?? ? ? ? ? ? ? ? ? ? ? :ssl-privatekey-file (cdr ssl-security) > ?? ? ? ? ? ? ? ? ? ? ? :port (get-config-value :website-port)) > > 2010/9/1 Hans H?bner >> >> Semion, >> >> can you please supply us with a minimal test case and pointers to the >> certificate files that you have tried? >> >> Thanks, >> Hans >> >> On Wed, Sep 1, 2010 at 12:40, Semion Prihodko >> wrote: >> > Hi guys, >> > I built a website which runs on Hunchentoot. Now it's time to buy >> > ssl-certificate. When I downloaded QuickSSL Trial cert I found out that >> > not >> > all the browsers accept it. After a little research I found out that >> > there >> > is another certificate must be installed. This means it's a "chain root >> > certificate", not a "single root". But it seems Hunchentoot has no >> > capability to work with chained certificates. CL+SSL has an interesting >> > function called?USE-CERTIFICATE-CHAIN-FILE, but when I use it before >> > creation of my ssl-acceptor the second doesn't respond to browsers. What >> > can >> > I do in order to fix this issue? Thanks in advance. >> > _______________________________________________ >> > 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 > From semion.ababo at gmail.com Wed Sep 1 12:10:10 2010 From: semion.ababo at gmail.com (Semion Prihodko) Date: Wed, 1 Sep 2010 15:10:10 +0300 Subject: [hunchentoot-devel] Chained SSL-certificates support In-Reply-To: References: Message-ID: I have sent them to u. 2010/9/1 Hans H?bner > Please post links to the certificates, too. Thanks. > > On Wed, Sep 1, 2010 at 13:58, Semion Prihodko > wrote: > > The code is very simple. > > ;; begin of new code > > (cl+ssl:reload) > > (cl+ssl:use-certificate-chain-file "mysite.cer") ; my site > > (cl+ssl:use-certificate-chain-file "geotrust.cer") ; intermediate > > (cl+ssl:use-certificate-chain-file "geotrust+.cer") ; root > > ;; end of new code > > (make-instance 'ssl-acceptor > > :ssl-certificate-file (car ssl-security) > > :ssl-privatekey-file (cdr ssl-security) > > :port (get-config-value :website-port)) > > > > 2010/9/1 Hans H?bner > >> > >> Semion, > >> > >> can you please supply us with a minimal test case and pointers to the > >> certificate files that you have tried? > >> > >> Thanks, > >> Hans > >> > >> On Wed, Sep 1, 2010 at 12:40, Semion Prihodko > >> wrote: > >> > Hi guys, > >> > I built a website which runs on Hunchentoot. Now it's time to buy > >> > ssl-certificate. When I downloaded QuickSSL Trial cert I found out > that > >> > not > >> > all the browsers accept it. After a little research I found out that > >> > there > >> > is another certificate must be installed. This means it's a "chain > root > >> > certificate", not a "single root". But it seems Hunchentoot has no > >> > capability to work with chained certificates. CL+SSL has an > interesting > >> > function called USE-CERTIFICATE-CHAIN-FILE, but when I use it before > >> > creation of my ssl-acceptor the second doesn't respond to browsers. > What > >> > can > >> > I do in order to fix this issue? Thanks in advance. > >> > _______________________________________________ > >> > 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 edi at agharta.de Wed Sep 1 12:15:19 2010 From: edi at agharta.de (Edi Weitz) Date: Wed, 1 Sep 2010 14:15:19 +0200 Subject: [hunchentoot-devel] Chained SSL-certificates support In-Reply-To: References: Message-ID: Hmm, probably like this: http://httpd.apache.org/docs/2.0/mod/mod_ssl.html#sslcertificatechainfile On Wed, Sep 1, 2010 at 2:08 PM, Edi Weitz wrote: > I'm not familiar with chained certificates. ?How would you use your > certificate with Apache for example? > > Edi. > From vseloved at gmail.com Wed Sep 1 12:09:54 2010 From: vseloved at gmail.com (Vsevolod Dyomkin) Date: Wed, 1 Sep 2010 15:09:54 +0300 Subject: [hunchentoot-devel] Chained SSL-certificates support In-Reply-To: References: Message-ID: Hi Semion, you can put all your certificates in one file, first root, then intermediate, then your site. It should work that way Best regargs, Vsevolod On Wed, Sep 1, 2010 at 2:58 PM, Semion Prihodko wrote: > The code is very simple. > > ;; begin of new code > (cl+ssl:reload) > (cl+ssl:use-certificate-chain-file "mysite.cer") ; my site > (cl+ssl:use-certificate-chain-file "geotrust.cer") ; intermediate > (cl+ssl:use-certificate-chain-file "geotrust+.cer") ; root > ;; end of new code > > (make-instance 'ssl-acceptor > :ssl-certificate-file (car ssl-security) > :ssl-privatekey-file (cdr ssl-security) > :port (get-config-value :website-port)) > > > 2010/9/1 Hans H?bner > > Semion, >> >> can you please supply us with a minimal test case and pointers to the >> certificate files that you have tried? >> >> Thanks, >> Hans >> >> On Wed, Sep 1, 2010 at 12:40, Semion Prihodko >> wrote: >> > Hi guys, >> > I built a website which runs on Hunchentoot. Now it's time to buy >> > ssl-certificate. When I downloaded QuickSSL Trial cert I found out that >> not >> > all the browsers accept it. After a little research I found out that >> there >> > is another certificate must be installed. This means it's a "chain root >> > certificate", not a "single root". But it seems Hunchentoot has no >> > capability to work with chained certificates. CL+SSL has an interesting >> > function called USE-CERTIFICATE-CHAIN-FILE, but when I use it before >> > creation of my ssl-acceptor the second doesn't respond to browsers. What >> can >> > I do in order to fix this issue? Thanks in advance. >> > _______________________________________________ >> > 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 edi at agharta.de Wed Sep 1 12:45:06 2010 From: edi at agharta.de (Edi Weitz) Date: Wed, 1 Sep 2010 14:45:06 +0200 Subject: [hunchentoot-devel] Chained SSL-certificates support In-Reply-To: References: Message-ID: I just checked and the "chain" stuff seems to be available in LispWorks as well: http://www.lispworks.com/documentation/lw60/LW/html/lw-442.htm As Semion mentioned the existence of such a function in CL+SSL, it looks like it should be possible to support chained certificates in Hunchentoot in a portable way (meaning LW and the rest). So, if someone wants to send a patch... Edi. From semion.ababo at gmail.com Wed Sep 1 12:59:06 2010 From: semion.ababo at gmail.com (Semion Prihodko) Date: Wed, 1 Sep 2010 15:59:06 +0300 Subject: [hunchentoot-devel] Chained SSL-certificates support In-Reply-To: References: Message-ID: No, in that case I get ERR_SSL_PROTOCOL_ERROR 2010/9/1 Vsevolod Dyomkin > Hi Semion, > > you can put all your certificates in one file, first root, then > intermediate, then your site. It should work that way > > Best regargs, > Vsevolod > > > > On Wed, Sep 1, 2010 at 2:58 PM, Semion Prihodko wrote: > >> The code is very simple. >> >> ;; begin of new code >> (cl+ssl:reload) >> (cl+ssl:use-certificate-chain-file "mysite.cer") ; my site >> (cl+ssl:use-certificate-chain-file "geotrust.cer") ; intermediate >> (cl+ssl:use-certificate-chain-file "geotrust+.cer") ; root >> ;; end of new code >> >> (make-instance 'ssl-acceptor >> :ssl-certificate-file (car ssl-security) >> :ssl-privatekey-file (cdr ssl-security) >> :port (get-config-value :website-port)) >> >> >> 2010/9/1 Hans H?bner >> >> Semion, >>> >>> can you please supply us with a minimal test case and pointers to the >>> certificate files that you have tried? >>> >>> Thanks, >>> Hans >>> >>> On Wed, Sep 1, 2010 at 12:40, Semion Prihodko >>> wrote: >>> > Hi guys, >>> > I built a website which runs on Hunchentoot. Now it's time to buy >>> > ssl-certificate. When I downloaded QuickSSL Trial cert I found out that >>> not >>> > all the browsers accept it. After a little research I found out that >>> there >>> > is another certificate must be installed. This means it's a "chain root >>> > certificate", not a "single root". But it seems Hunchentoot has no >>> > capability to work with chained certificates. CL+SSL has an interesting >>> > function called USE-CERTIFICATE-CHAIN-FILE, but when I use it before >>> > creation of my ssl-acceptor the second doesn't respond to browsers. >>> What can >>> > I do in order to fix this issue? Thanks in advance. >>> > _______________________________________________ >>> > 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 edi at agharta.de Wed Sep 1 12:08:38 2010 From: edi at agharta.de (Edi Weitz) Date: Wed, 1 Sep 2010 14:08:38 +0200 Subject: [hunchentoot-devel] Chained SSL-certificates support In-Reply-To: References: Message-ID: I'm not familiar with chained certificates. How would you use your certificate with Apache for example? Edi. From semion.ababo at gmail.com Wed Sep 1 13:14:38 2010 From: semion.ababo at gmail.com (Semion Prihodko) Date: Wed, 1 Sep 2010 16:14:38 +0300 Subject: [hunchentoot-devel] Chained SSL-certificates support In-Reply-To: References: Message-ID: I think Apache supports adding one additional certificate. To do that you must add the following line: *SSLCACertificateFile* cert_filename in configuration file. 2010/9/1 Edi Weitz > I'm not familiar with chained certificates. How would you use your > certificate with Apache for example? > > Edi. > > _______________________________________________ > 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 billstclair at gmail.com Wed Sep 1 14:03:53 2010 From: billstclair at gmail.com (Bill St. Clair) Date: Wed, 1 Sep 2010 10:03:53 -0400 Subject: [hunchentoot-devel] Chained SSL-certificates support In-Reply-To: References: Message-ID: I use: SSLCertificateFile /usr/local/etc/apache22/certs/billstclair.com.crt SSLCertificateChainFile /usr/local/etc/apache22/certs/gd_bundle.crt SSLCertificateKeyFile /usr/local/etc/apache22/certs/billstclair.com.key billstclair.com.crt contains my certificate, signed by the GoDaddy CA. gd_bundle.crt contains the GoDaddy CA certificate and another CA certificate that signs it. -Bill On Wed, Sep 1, 2010 at 9:14 AM, Semion Prihodko wrote: > I think Apache supports adding one additional certificate. To do that you > must add the following line: > SSLCACertificateFile?cert_filename > in configuration file. > > 2010/9/1 Edi Weitz >> >> I'm not familiar with chained certificates. ?How would you use your >> certificate with Apache for example? >> >> Edi. >> >> _______________________________________________ >> 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 > From semion.ababo at gmail.com Wed Sep 1 14:46:18 2010 From: semion.ababo at gmail.com (Semion Prihodko) Date: Wed, 1 Sep 2010 17:46:18 +0300 Subject: [hunchentoot-devel] Chained SSL-certificates support In-Reply-To: References: Message-ID: This is really a problem, because most of certificates that can be purchased use intermediate root certificate... really don't understand why this issue was not taken into consideration in Hunchentoot design. 2010/9/1 Bill St. Clair > I use: > > SSLCertificateFile /usr/local/etc/apache22/certs/billstclair.com.crt > SSLCertificateChainFile /usr/local/etc/apache22/certs/gd_bundle.crt > SSLCertificateKeyFile > /usr/local/etc/apache22/certs/billstclair.com.key > > billstclair.com.crt contains my certificate, signed by the GoDaddy CA. > gd_bundle.crt contains the GoDaddy CA certificate and another CA > certificate that signs it. > > -Bill > > On Wed, Sep 1, 2010 at 9:14 AM, Semion Prihodko > wrote: > > I think Apache supports adding one additional certificate. To do that you > > must add the following line: > > SSLCACertificateFile cert_filename > > in configuration file. > > > > 2010/9/1 Edi Weitz > >> > >> I'm not familiar with chained certificates. How would you use your > >> certificate with Apache for example? > >> > >> Edi. > >> > >> _______________________________________________ > >> 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 Wed Sep 1 14:56:41 2010 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Wed, 1 Sep 2010 16:56:41 +0200 Subject: [hunchentoot-devel] Chained SSL-certificates support In-Reply-To: References: Message-ID: On Wed, Sep 1, 2010 at 16:46, Semion Prihodko wrote: > This is really a problem, because most of certificates that can be purchased > use intermediate root certificate... really don't understand why this issue > was not taken into?consideration in Hunchentoot design. We're sorry to hear that Hunchentoot does not meet your requirements. We implemented the features that we need, and chained certificate support was not required by us. You are welcome to send a patch. We can also offer paid support. http://weitz.de/patches.html -Hans From semion.ababo at gmail.com Wed Sep 1 15:20:35 2010 From: semion.ababo at gmail.com (Semion Prihodko) Date: Wed, 1 Sep 2010 18:20:35 +0300 Subject: [hunchentoot-devel] Chained SSL-certificates support In-Reply-To: References: Message-ID: Actually I think that Hunchentoot is a great webserver, so don't take it to heart. And I very appreciate what you all guys do. By the way the issue is solved - no patch needed. The problem was in documentation of CL+SSL:USE-CERTIFICATE-CHAIN-FILE which was not clear. After reading the appropriate OpenSSL call reference I understood that it's needed to add only a single file. In that file I need to place 2 certificates (in pem format): the website's and the following intermediate CA's. Now it's working. Thanks a lot. 2010/9/1 Hans H?bner > On Wed, Sep 1, 2010 at 16:46, Semion Prihodko > wrote: > > This is really a problem, because most of certificates that can be > purchased > > use intermediate root certificate... really don't understand why this > issue > > was not taken into consideration in Hunchentoot design. > > We're sorry to hear that Hunchentoot does not meet your requirements. > We implemented the features that we need, and chained certificate > support was not required by us. You are welcome to send a patch. We > can also offer paid support. > > http://weitz.de/patches.html > > -Hans > > _______________________________________________ > 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 pepe_ml at gmx.net Wed Sep 1 15:25:40 2010 From: pepe_ml at gmx.net (Steffen Schulz) Date: Wed, 1 Sep 2010 17:25:40 +0200 Subject: [hunchentoot-devel] Chained SSL-certificates support In-Reply-To: References: Message-ID: <20100901152540.GA20583@cbg.dyndns.org> Hi, I had a similar problem some time ago but no time to investigate. I think the chain cert must be provided at a separate place in the SSL handshake. There's a special openssl function and it seems to be exported in cl+ssl: | CL+SSL:USE-CERTIFICATE-CHAIN-FILE (certificate-chain-file) | | Loads a PEM encoded certificate chain file certificate-chain-file and | adds the chain to global context. The certificates must be sorted | starting with the subject's certificate (actual client or server | certificate), followed by intermediate CA certificates if applicable, | and ending at the highest level (root) CA. So its probably not very hard. There was also a patch available somewhere online but it didn't work for me back then. HTH, Steffen From edi at agharta.de Wed Sep 1 15:01:20 2010 From: edi at agharta.de (Edi Weitz) Date: Wed, 1 Sep 2010 17:01:20 +0200 Subject: [hunchentoot-devel] Chained SSL-certificates support In-Reply-To: References: Message-ID: On Wed, Sep 1, 2010 at 4:46 PM, Semion Prihodko wrote: > This is really a problem, because most of certificates that can be purchased > use intermediate root certificate... really don't understand why this issue > was not taken into?consideration in Hunchentoot design. This is the way open source software works. Some hackers write code they need and give it away for free, others add features they deem worthwhile, and so on. If you need something that's not in there, add it yourself or pay someone to do it for you. The general rule is: You get what you paid for... Edi. From ron at flownet.com Sun Sep 12 07:06:06 2010 From: ron at flownet.com (Ron Garret) Date: Sun, 12 Sep 2010 00:06:06 -0700 Subject: [hunchentoot-devel] Unexpected result from CL-WEBDAV Message-ID: I tried the following to create a write-only DAV directory: (defmethod accept-request-p ((resource-class (eql 'authorized-file-resource)) request) "We just use the method for FILE-RESOURCE." (if (eql (tbnl:request-method*) :get) nil (accept-request-p 'file-resource request))) but instead of getting a "resource not available" when I try to get a file I instead get the hunchentoot default page. Needless to say, this is not what I expected. Is this a bug in cl-webdav, or a bug in my expectations? Thanks, rg From fahree at gmail.com Sun Sep 12 23:39:40 2010 From: fahree at gmail.com (=?ISO-8859-1?Q?Far=E9?=) Date: Sun, 12 Sep 2010 19:39:40 -0400 Subject: [hunchentoot-devel] 'max-threads' behavior for Hunchentoot In-Reply-To: References: <96F4A9B1-5603-4DE1-9144-415C9251DAA5@itasoftware.com> <4C05217C.4040406@itasoftware.com> <16493326-0713-4954-8976-19ED0C10D74C@itasoftware.com> <836C1566-0760-4000-AAA9-440FBAAB51EA@itasoftware.com> <586901B0-D79A-4AE5-908F-4FFEE9E3AF38@itasoftware.com> <18913F0E-C4B7-4044-8D02-45BCBBA0CDDE@itasoftware.com> Message-ID: Dear Edi, is there anything I can do to improve the patch that would help it make it to the official upstream hunchentoot? [ Fran?ois-Ren? ?VB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Any time you're asking the user to make a choice they don't care about, you have failed the user ? Jeff Atwood On 24 August 2010 22:16, Far? wrote: > Dear Edi, > > Here's a revised patch against the current svn. It's xcvb and version > changes reverted, otherwise what I'm running at ITA, and it seems to > be passing the QRes precheckin. It looks like it passes the elementary > test under Lispworks, but I don't personally have a working Lispworks > setup, so I can't say (will it work on LW Personal?). > > Can you review and apply if satisfactory? > >> Yes, the LispWorks version of Hunchentoot (which is the original >> Hunchentoot which only ran on LW) doesn't use any of the compatibility >> libs like BT, usocket, and cl+ssl. ?I want it to stay that way - the >> less dependencies, the better. >> > Understood. I also saw that you defined trivial wrappers rather than > imported LW symbols, and kept things that way. > >> Can't you just comment out all the new stuff with #-:lispworks? ?As I >> said, I'll take care of the LW version. >> > Scott did some work so it compiles under Lispworks, and > though it's wholly untested, I fixed it rather than scrapped it. > Please take it with a pinch of salt. > > > Suggested commit message: > > ? Extend Hunchentoot's 'one-thread-per-connection-taskmaster' > ? ? to support 'max-threads' semantics, i.e., don't create > ? ? a new thread if we've max out. > > ? Add a 'pooled-thread-per-connection-taskmaster' that will > ? ? eventually use a thread pool, if profiling indicates. > ? Fix the 'handle-incoming-connection' to implement the > ? ? new behavior. > ? Add a commented-out implementation of 'accept-connections' > ? ? that might give better performance. ?This needs to be > ? ? discussed with the Hunchentoot maintainers. > > ? Address the review comments and discussions between Scott McKay > ? and Hans Huebner. > ? Also correctly issue HTTP 503 when the server runs out of threads. > > (Work by Scott McKay, merge by Fran?ois-Ren? Rideau) > > [ Fran?ois-Ren? ?VB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] > Moving parts in rubbing contact require lubrication to avoid excessive wear. > Honorifics and formal politeness provide lubrication where people rub together. > Often the very young, the untraveled, the na?ve, the unsophisticated deplore > these formalities as "empty", "meaningless", or "dishonest", and scorn to use > them. No matter how "pure" their motives, they thereby throw sand into > machinery that does not work too well at best. > ? ? ? ?? Robert Heinlein, "Time Enough For Love" > From edi at agharta.de Mon Sep 13 14:25:57 2010 From: edi at agharta.de (Edi Weitz) Date: Mon, 13 Sep 2010 16:25:57 +0200 Subject: [hunchentoot-devel] 'max-threads' behavior for Hunchentoot In-Reply-To: References: <96F4A9B1-5603-4DE1-9144-415C9251DAA5@itasoftware.com> <4C05217C.4040406@itasoftware.com> <16493326-0713-4954-8976-19ED0C10D74C@itasoftware.com> <836C1566-0760-4000-AAA9-440FBAAB51EA@itasoftware.com> <586901B0-D79A-4AE5-908F-4FFEE9E3AF38@itasoftware.com> <18913F0E-C4B7-4044-8D02-45BCBBA0CDDE@itasoftware.com> Message-ID: Buy me some time... :) Nah, not really. Sorry for the delay. I've been busy recently and just returned from a trip to New York. I'll try to squeeze this in in the next days. On Mon, Sep 13, 2010 at 1:39 AM, Far? wrote: > Dear Edi, > > is there anything I can do to improve the patch that would help it > make it to the official upstream hunchentoot? > > [ Fran?ois-Ren? ?VB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] > Any time you're asking the user to make a choice they don't care about, > you have failed the user ? Jeff Atwood > > > > > On 24 August 2010 22:16, Far? wrote: >> Dear Edi, >> >> Here's a revised patch against the current svn. It's xcvb and version >> changes reverted, otherwise what I'm running at ITA, and it seems to >> be passing the QRes precheckin. It looks like it passes the elementary >> test under Lispworks, but I don't personally have a working Lispworks >> setup, so I can't say (will it work on LW Personal?). >> >> Can you review and apply if satisfactory? >> >>> Yes, the LispWorks version of Hunchentoot (which is the original >>> Hunchentoot which only ran on LW) doesn't use any of the compatibility >>> libs like BT, usocket, and cl+ssl. ?I want it to stay that way - the >>> less dependencies, the better. >>> >> Understood. I also saw that you defined trivial wrappers rather than >> imported LW symbols, and kept things that way. >> >>> Can't you just comment out all the new stuff with #-:lispworks? ?As I >>> said, I'll take care of the LW version. >>> >> Scott did some work so it compiles under Lispworks, and >> though it's wholly untested, I fixed it rather than scrapped it. >> Please take it with a pinch of salt. >> >> >> Suggested commit message: >> >> ? Extend Hunchentoot's 'one-thread-per-connection-taskmaster' >> ? ? to support 'max-threads' semantics, i.e., don't create >> ? ? a new thread if we've max out. >> >> ? Add a 'pooled-thread-per-connection-taskmaster' that will >> ? ? eventually use a thread pool, if profiling indicates. >> ? Fix the 'handle-incoming-connection' to implement the >> ? ? new behavior. >> ? Add a commented-out implementation of 'accept-connections' >> ? ? that might give better performance. ?This needs to be >> ? ? discussed with the Hunchentoot maintainers. >> >> ? Address the review comments and discussions between Scott McKay >> ? and Hans Huebner. >> ? Also correctly issue HTTP 503 when the server runs out of threads. >> >> (Work by Scott McKay, merge by Fran?ois-Ren? Rideau) >> >> [ Fran?ois-Ren? ?VB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] >> Moving parts in rubbing contact require lubrication to avoid excessive wear. >> Honorifics and formal politeness provide lubrication where people rub together. >> Often the very young, the untraveled, the na?ve, the unsophisticated deplore >> these formalities as "empty", "meaningless", or "dishonest", and scorn to use >> them. No matter how "pure" their motives, they thereby throw sand into >> machinery that does not work too well at best. >> ? ? ? ?? Robert Heinlein, "Time Enough For Love" >> > > From edi at agharta.de Tue Sep 14 22:22:22 2010 From: edi at agharta.de (Edi Weitz) Date: Wed, 15 Sep 2010 00:22:22 +0200 Subject: [hunchentoot-devel] Unexpected result from CL-WEBDAV In-Reply-To: References: Message-ID: How did you set up your WebDAV server? Surely, this is not the only code you have? Did you create a dispatcher for your class and did you activate it? Edi. On Sun, Sep 12, 2010 at 9:06 AM, Ron Garret wrote: > I tried the following to create a write-only DAV directory: > > (defmethod accept-request-p ((resource-class (eql 'authorized-file-resource)) request) > ?"We just use the method for FILE-RESOURCE." > ?(if (eql (tbnl:request-method*) :get) > ? ?nil > ? ?(accept-request-p 'file-resource request))) > > but instead of getting a "resource not available" when I try to get a file I instead get the hunchentoot default page. ?Needless to say, this is not what I expected. ?Is this a bug in cl-webdav, or a bug in my expectations? > > Thanks, > rg > > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > > From edi at agharta.de Tue Sep 14 22:29:29 2010 From: edi at agharta.de (Edi Weitz) Date: Wed, 15 Sep 2010 00:29:29 +0200 Subject: [hunchentoot-devel] Unexpected result from CL-WEBDAV In-Reply-To: References: Message-ID: Sorry, I misread your code. No, this is not a bug, it's expected behavior and what's written in the documentation. By returning NIL you're saying that you don't want to handle this request, so the next dispatcher is tried which in your case seems to be Hunchentoot's default dispatcher. If by "resource not available" you mean the "404 not found" message, you need to look at the resource-exists generic function. Edi. On Wed, Sep 15, 2010 at 12:22 AM, Edi Weitz wrote: > How did you set up your WebDAV server? ?Surely, this is not the only > code you have? ?Did you create a dispatcher for your class and did you > activate it? > > Edi. > > > On Sun, Sep 12, 2010 at 9:06 AM, Ron Garret wrote: >> I tried the following to create a write-only DAV directory: >> >> (defmethod accept-request-p ((resource-class (eql 'authorized-file-resource)) request) >> ?"We just use the method for FILE-RESOURCE." >> ?(if (eql (tbnl:request-method*) :get) >> ? ?nil >> ? ?(accept-request-p 'file-resource request))) >> >> but instead of getting a "resource not available" when I try to get a file I instead get the hunchentoot default page. ?Needless to say, this is not what I expected. ?Is this a bug in cl-webdav, or a bug in my expectations? >> >> Thanks, >> rg >> >> >> _______________________________________________ >> tbnl-devel site list >> tbnl-devel at common-lisp.net >> http://common-lisp.net/mailman/listinfo/tbnl-devel >> >> > From ron at flownet.com Fri Sep 17 06:08:02 2010 From: ron at flownet.com (Ron Garret) Date: Thu, 16 Sep 2010 23:08:02 -0700 Subject: [hunchentoot-devel] Deploying CCL on a production server Message-ID: I'm getting close to deploying CCL on a production server, which has forced me to reluctantly reach the following conclusion: the fact that Lisp allows code to be changed dynamically means that unless you are extremely disciplined about how you patch the code in your server, it is not at all difficult to end up in a situation where the server needs to be restarted. When that happens, it would be nice not to have the server machine go completely dead, but instead to respond with a nice "Server temporarily unavailable" page, and maybe even continue to serve static content. So much as I'm a fan of Lisp and Hunchentoot, it seems to me that it's not a good idea to use that combination as the front-end of a production application, but instead to deploy the Lisp app as a FastCGI or the back-end of a proxy server setup. If anyone disagrees with this analysis or has a better idea of how to deploy a Lisp app onto a production server I would love to hear it. Thanks, rg From hans.huebner at gmail.com Fri Sep 17 06:17:29 2010 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Fri, 17 Sep 2010 08:17:29 +0200 Subject: [hunchentoot-devel] Deploying CCL on a production server In-Reply-To: References: Message-ID: On Fri, Sep 17, 2010 at 08:08, Ron Garret wrote: > I'm getting close to deploying CCL on a production server, which has forced me to reluctantly reach the following conclusion: the fact that Lisp allows code to be changed dynamically means that unless you are extremely disciplined about how you patch the code in your server, it is not at all difficult to end up in a situation where the server needs to be restarted. ?When that happens, it would be nice not to have the server machine go completely dead, but instead to respond with a nice "Server temporarily unavailable" page, and maybe even continue to serve static content. ?So much as I'm a fan of Lisp and Hunchentoot, it seems to me that it's not a good idea to use that combination as the front-end of a production application, but instead to deploy the Lisp app as a FastCGI or the back-end of a proxy server setup. > > If anyone disagrees with this analysis or has a better idea of how to deploy a Lisp app onto a production server I would love to hear it. I favor this approach, too. Two years ago, I evaluated a few caching proxies and blogged about that (http://netzhansa.blogspot.com/2008/07/building-load-resilient-web-servers.html), you might find some interesting info in that post. -Hans From smanek at gmail.com Fri Sep 17 06:23:29 2010 From: smanek at gmail.com (Shaneal Manek) Date: Fri, 17 Sep 2010 01:23:29 -0500 Subject: [hunchentoot-devel] Deploying CCL on a production server In-Reply-To: References: Message-ID: Generally, I deploy Hunchentoot behind a reverse proxy (just nginx for single-instance deployments, or HAProxy and nginx for more complex setups). In either case, I let nginx serve the static content (no need to waste the relatively expensive Lisp threads for serving images). In the single-hunchentoot case, nginx can serve a static error page when the hunchentoot instance is down. On the other hand, if you have a HAProxy in front of multiple hunchentoots, then as long as one hunchentoot is still up your site can continue with no downtime. -Shaneal On Fri, Sep 17, 2010 at 1:08 AM, Ron Garret wrote: > I'm getting close to deploying CCL on a production server, which has forced me to reluctantly reach the following conclusion: the fact that Lisp allows code to be changed dynamically means that unless you are extremely disciplined about how you patch the code in your server, it is not at all difficult to end up in a situation where the server needs to be restarted. ?When that happens, it would be nice not to have the server machine go completely dead, but instead to respond with a nice "Server temporarily unavailable" page, and maybe even continue to serve static content. ?So much as I'm a fan of Lisp and Hunchentoot, it seems to me that it's not a good idea to use that combination as the front-end of a production application, but instead to deploy the Lisp app as a FastCGI or the back-end of a proxy server setup. From ron at flownet.com Sun Sep 19 01:14:14 2010 From: ron at flownet.com (Ron Garret) Date: Sat, 18 Sep 2010 18:14:14 -0700 Subject: [hunchentoot-devel] [Openmcl-devel] Deploying CCL on a production server In-Reply-To: References: Message-ID: <4EEA64F3-240F-4E22-A2BF-3728BEA57377@flownet.com> On Sep 16, 2010, at 11:17 PM, Hans H?bner wrote: > On Fri, Sep 17, 2010 at 08:08, Ron Garret wrote: >> I'm getting close to deploying CCL on a production server, which has forced me to reluctantly reach the following conclusion: the fact that Lisp allows code to be changed dynamically means that unless you are extremely disciplined about how you patch the code in your server, it is not at all difficult to end up in a situation where the server needs to be restarted. When that happens, it would be nice not to have the server machine go completely dead, but instead to respond with a nice "Server temporarily unavailable" page, and maybe even continue to serve static content. So much as I'm a fan of Lisp and Hunchentoot, it seems to me that it's not a good idea to use that combination as the front-end of a production application, but instead to deploy the Lisp app as a FastCGI or the back-end of a proxy server setup. >> >> If anyone disagrees with this analysis or has a better idea of how to deploy a Lisp app onto a production server I would love to hear it. > > I favor this approach, too. Two years ago, I evaluated a few caching > proxies and blogged about that > (http://netzhansa.blogspot.com/2008/07/building-load-resilient-web-servers.html), > you might find some interesting info in that post. Thanks! For the moment I've settled on nginx for my front-end. So I have nginx running on port 80 forwarding requests to HT on some other port, but HT is still visible to the outside world, which seems like a bad thing security-wise. So my next question is: what is the best way to hide HT from the outside world? It seems the HT cannot serve a unix domain socket, and doesn't have IP-based access control built in. The only other solution would seem to be a firewall of some sort. Is that what people who use HT behind a front end generally do, or is there a more straightforward solution that I've overlooked? Thanks, rg From edi at agharta.de Sun Sep 19 01:55:07 2010 From: edi at agharta.de (Edi Weitz) Date: Sun, 19 Sep 2010 03:55:07 +0200 Subject: [hunchentoot-devel] [Openmcl-devel] Deploying CCL on a production server In-Reply-To: <4EEA64F3-240F-4E22-A2BF-3728BEA57377@flownet.com> References: <4EEA64F3-240F-4E22-A2BF-3728BEA57377@flownet.com> Message-ID: On Sun, Sep 19, 2010 at 3:14 AM, Ron Garret wrote: > > or is there a more straightforward solution that I've overlooked? Yes. Use the :address initarg of the acceptor class and let it only listen on localhost - assuming the proxy is on the same server. From amalawi at gmail.com Sun Sep 19 05:05:41 2010 From: amalawi at gmail.com (Ala'a Mohammad) Date: Sun, 19 Sep 2010 09:05:41 +0400 Subject: [hunchentoot-devel] Deploying CCL on a production server In-Reply-To: References: Message-ID: Later, you may consider Varnish (http://www.varnish-cache.org/) in front of hunchentoot. Ala'a From ron at flownet.com Sun Sep 19 05:50:14 2010 From: ron at flownet.com (Ron Garret) Date: Sat, 18 Sep 2010 22:50:14 -0700 Subject: [hunchentoot-devel] Deploying CCL on a production server In-Reply-To: References: Message-ID: <53E37613-A973-4527-AE9E-11B5CDC64167@flownet.com> I decided against varnish because of what Hans wrote here: http://netzhansa.blogspot.com/2008/07/building-load-resilient-web-servers.html But that was two years ago. Maybe things have improved. rg On Sep 18, 2010, at 10:05 PM, Ala'a Mohammad wrote: > Later, you may consider Varnish (http://www.varnish-cache.org/) in > front of hunchentoot. > > Ala'a From ron at flownet.com Sun Sep 19 05:56:04 2010 From: ron at flownet.com (Ron Garret) Date: Sat, 18 Sep 2010 22:56:04 -0700 Subject: [hunchentoot-devel] [Openmcl-devel] Deploying CCL on a production server In-Reply-To: References: <4EEA64F3-240F-4E22-A2BF-3728BEA57377@flownet.com> Message-ID: <121452A4-5D9F-4B1B-A0A6-AF10B0AA0770@flownet.com> On Sep 18, 2010, at 6:55 PM, Edi Weitz wrote: > On Sun, Sep 19, 2010 at 3:14 AM, Ron Garret wrote: >> >> or is there a more straightforward solution that I've overlooked? > > Yes. Use the :address initarg of the acceptor class and let it only > listen on localhost - assuming the proxy is on the same server. Brilliant! Just what I needed. Thanks! rg From ndj at bitart.cc Thu Sep 23 12:57:45 2010 From: ndj at bitart.cc (Nico de Jager) Date: Thu, 23 Sep 2010 14:57:45 +0200 Subject: [hunchentoot-devel] Exporting session-start & session-id Message-ID: <87hbhgd3cm.fsf@tux.studbook.co.za> Hi Although the Hunchentoot documentation says "... the internal structure of SESSION objects should be considered opaque ..." and the functionality of session-id and session-start can be trivially implemented, I am wondering if these two readers can be exported? session-start is useful for seeing how long users have been on the system. session-id is useful for session identity. Why re-implement them when Hunchentoot already has the functionality? Regards. Nico From hans.huebner at gmail.com Thu Sep 23 13:30:38 2010 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Thu, 23 Sep 2010 15:30:38 +0200 Subject: [hunchentoot-devel] Exporting session-start & session-id In-Reply-To: <87hbhgd3cm.fsf@tux.studbook.co.za> References: <87hbhgd3cm.fsf@tux.studbook.co.za> Message-ID: On Thu, Sep 23, 2010 at 14:57, Nico de Jager wrote: > Although the Hunchentoot documentation says "... the internal structure > of SESSION objects should be considered opaque ..." and the > functionality of session-id and session-start can be trivially > implemented, I am wondering if these two readers can be > exported? > > session-start is useful for seeing how long users have been on > the system. session-id is useful for session identity. Why re-implement > them when Hunchentoot already has the functionality? I am not opposed - Send a patch for review (http://weitz.de/patches.html). -Hans From ndj at bitart.cc Fri Sep 24 08:47:19 2010 From: ndj at bitart.cc (Nico de Jager) Date: Fri, 24 Sep 2010 10:47:19 +0200 Subject: [hunchentoot-devel] Exporting session-start & session-id In-Reply-To: ("Hans =?utf-8?Q?H=C3=BCbner=22's?= message of "Thu, 23 Sep 2010 15:30:38 +0200") References: <87hbhgd3cm.fsf@tux.studbook.co.za> Message-ID: <87eicja5pk.fsf@tux.studbook.co.za> Hans H?bner writes: > On Thu, Sep 23, 2010 at 14:57, Nico de Jager wrote: >> Although the Hunchentoot documentation says "... the internal structure >> of SESSION objects should be considered opaque ..." and the >> functionality of session-id and session-start can be trivially >> implemented, I am wondering if these two readers can be >> exported? >> >> session-start is useful for seeing how long users have been on >> the system. session-id is useful for session identity. Why re-implement >> them when Hunchentoot already has the functionality? > > I am not opposed - Send a patch for review > (http://weitz.de/patches.html). Ok, thanks - no problem. I feel stupid asking this, but how do I get the svn version of Hunchentoot: $ svn co http://bknr.net/trac/browser/trunk/thirdparty/hunchentoot svn: XML data was not well-formed Also, do I have to update that ugly doc/index.xml file in a text editor, are there some kind of tool to edit it, or do you generate (parts of) it from the source code? From hans.huebner at gmail.com Fri Sep 24 09:00:37 2010 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Fri, 24 Sep 2010 11:00:37 +0200 Subject: [hunchentoot-devel] Exporting session-start & session-id In-Reply-To: <87eicja5pk.fsf@tux.studbook.co.za> References: <87hbhgd3cm.fsf@tux.studbook.co.za> <87eicja5pk.fsf@tux.studbook.co.za> Message-ID: On Fri, Sep 24, 2010 at 10:47, Nico de Jager wrote: > Ok, thanks - no problem. I feel stupid asking this, but how do I get the > svn version of Hunchentoot: > > $ svn co http://bknr.net/trac/browser/trunk/thirdparty/hunchentoot > svn: XML data was not well-formed svn co http://bknr.net/svn/ediware will get you the whole ediware tree, which includes matching development versions for Hunchentoot and its dependencies. > Also, do I have to update that ugly doc/index.xml file in a text editor, > are there some kind of tool to edit it, or do you generate (parts of) it > from the source code? It is an XML file, you can use any editor to edit it. It is the master copy of the documentation. There are tools that we used to extract the docstrings into the XML documentation, but they are not readily deployable. I'd suggest that you add the docstrings and then copy them to the XML file manually. Please make sure that it is still well formed after you've modified it (xmllint can help with that). Emacs 23 includes the nXML mode, which validates well-formedness on the fly. -Hans From ndj at bitart.cc Sat Sep 25 13:31:07 2010 From: ndj at bitart.cc (Nico de Jager) Date: Sat, 25 Sep 2010 15:31:07 +0200 Subject: [hunchentoot-devel] Exporting session-start & session-id In-Reply-To: ("Hans =?utf-8?Q?H=C3=BCbner=22's?= message of "Fri, 24 Sep 2010 11:00:37 +0200") References: <87hbhgd3cm.fsf@tux.studbook.co.za> <87eicja5pk.fsf@tux.studbook.co.za> Message-ID: <877hiane5g.fsf@bitart.cc> Hans H?bner writes: > On Fri, Sep 24, 2010 at 10:47, Nico de Jager wrote: >> Ok, thanks - no problem. I feel stupid asking this, but how do I get the >> svn version of Hunchentoot: >> >> $ svn co http://bknr.net/trac/browser/trunk/thirdparty/hunchentoot >> svn: XML data was not well-formed > > svn co http://bknr.net/svn/ediware > > will get you the whole ediware tree, which includes matching > development versions for Hunchentoot and its dependencies. > >> Also, do I have to update that ugly doc/index.xml file in a text editor, >> are there some kind of tool to edit it, or do you generate (parts of) it >> from the source code? > > It is an XML file, you can use any editor to edit it. It is the > master copy of the documentation. There are tools that we used to > extract the docstrings into the XML documentation, but they are not > readily deployable. I'd suggest that you add the docstrings and then > copy them to the XML file manually. > > Please make sure that it is still well formed after you've modified it > (xmllint can help with that). Emacs 23 includes the nXML mode, which > validates well-formedness on the fly. Attached, please find the patch. I added the new documentation at the end of the "Sessions" section, but will be disappointed if Edi don't make me rearrange it somehow :-) -------------- next part -------------- A non-text attachment was scrubbed... Name: hunchentoot_svn.patch Type: text/x-diff Size: 1382 bytes Desc: hunchentoot_svn.patch URL: From linkfly1 at newmail.ru Wed Sep 29 14:30:15 2010 From: linkfly1 at newmail.ru (=?KOI8-R?Q?=F3=C5=D2=C7=C5=CA=20=EB=C1=D4=D2=C5=D7=C9=DE?=) Date: Wed, 29 Sep 2010 18:30:15 +0400 Subject: [hunchentoot-devel] Sergey Katrevich. Add mime-type to *mime-type-list* Message-ID: <0a3cfd34a4bc77f04df8945d497cb7413fe131d9@mail.qip.ru> Hello. I am need in mime-type for *.gz files. -------------- next part -------------- A non-text attachment was scrubbed... Name: mime-types.lisp.patch.tar Type: application/x-tar Size: 10240 bytes Desc: not available URL: From sky at viridian-project.de Wed Sep 29 15:26:54 2010 From: sky at viridian-project.de (Leslie P. Polzer) Date: Wed, 29 Sep 2010 17:26:54 +0200 (CEST) Subject: [hunchentoot-devel] Sergey Katrevich. Add mime-type to *mime-type-list* In-Reply-To: <0a3cfd34a4bc77f04df8945d497cb7413fe131d9@mail.qip.ru> References: <0a3cfd34a4bc77f04df8945d497cb7413fe131d9@mail.qip.ru> Message-ID: <75180730d7bf166c57afbbb34c079833.squirrel@mail.stardawn.org> ?????? ???????? wrote: > Hello. > I am need in mime-type for *.gz files. application/x-gzip seems to be popular. Some more: http://filext.com/file-extension/GZ Leslie