From dlw at itasoftware.com Mon Mar 1 22:30:46 2010 From: dlw at itasoftware.com (Daniel Weinreb) Date: Mon, 01 Mar 2010 17:30:46 -0500 Subject: [hunchentoot-devel] Hunchentoot treatment of unhandled conditions Message-ID: <4B8C4016.1050604@itasoftware.com> We just ran into a problem regarding Hunchntoot's handling of unexpected conditions. Hunchentoot's accept-connections called usocket:socket-accept, which signaled a usocket:unknown-error. Nothing handled this condition. This happened in a server, which crashes (rather than going into the interactive debugger) when there is an unhandled condition. I'd like to have a way to do something like this in Hunchentoot. I see that the latest version goes further in this direction by having a handler-bind for "error" in the handle-request method. Unfortunately, in our case, the problem occurs before that is in effect. Are there any plans regarding this, or advice about it? Thanks. -- Dan From hans.huebner at gmail.com Tue Mar 2 06:50:17 2010 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Tue, 2 Mar 2010 07:50:17 +0100 Subject: [hunchentoot-devel] Hunchentoot treatment of unhandled conditions In-Reply-To: <4B8C4016.1050604@itasoftware.com> References: <4B8C4016.1050604@itasoftware.com> Message-ID: On Mon, Mar 1, 2010 at 23:30, Daniel Weinreb wrote: > Hunchentoot's accept-connections called usocket:socket-accept, > which signaled a usocket:unknown-error. ?Nothing handled this > condition. ?This happened in a server, which crashes (rather than > going into the interactive debugger) when there is an unhandled > condition. [...] > Are there any plans regarding this, or advice about it? I do not think that Hunchentoot should continue as if nothing happened when usocket:socket-accept signals an unknown condition. After all, something bad could have happened to the socket, making the following select hang forever or the following accept just signal the same error again, both being undesireable (hanging vs. busy looping). The real question is: What is the original error that was converted into an unsocket:unknown-error? The condition has a real-error slot that can be examined to find out (and the print method prints it using "The condition ~A occured."). Once the original error is known, it can be decided how usocket must be fixed to map the platform specific error to a usocket condition class and if Hunchentoot can safely ignore this error when it occurs during an accept. Please let us know what you find out. -Hans From dlw at itasoftware.com Tue Mar 2 15:01:20 2010 From: dlw at itasoftware.com (Daniel Weinreb) Date: Tue, 02 Mar 2010 10:01:20 -0500 Subject: [hunchentoot-devel] Hunchentoot treatment of unhandled conditions In-Reply-To: References: <4B8C4016.1050604@itasoftware.com> Message-ID: <4B8D2840.4080109@itasoftware.com> Hans H?bner wrote: > On Mon, Mar 1, 2010 at 23:30, Daniel Weinreb wrote: > >> Hunchentoot's accept-connections called usocket:socket-accept, >> which signaled a usocket:unknown-error. Nothing handled this >> condition. This happened in a server, which crashes (rather than >> going into the interactive debugger) when there is an unhandled >> condition. >> > > [...] > > >> Are there any plans regarding this, or advice about it? >> > > I do not think that Hunchentoot should continue as if nothing happened > when usocket:socket-accept signals an unknown condition. Yes, I agree. I was thinking in terms of providing a way for the application using Hunchentoot to have a way of controlling what happens next in such a circumstance, such as logging, notifying some other process, etc. > After all, > something bad could have happened to the socket, making the following > select hang forever or the following accept just signal the same error > again, both being undesireable (hanging vs. busy looping). > > The real question is: What is the original error that was converted > into an unsocket:unknown-error? In this case, it was an errno 24, which is EMFILE, "too many open files". Yes, ideally usocket would have a generic condition for this. But from my point of view, the most important thing is to have some way to control what happens in the face of a condition that we cannot anticipate. It would be something like the existing handle-message's handler-bind, but "closer to the base of the stack" so that it would handle conditions signaled within, e.g., accept-connection. Thanks. -- Dan > The condition has a real-error slot > that can be examined to find out (and the print method prints it using > "The condition ~A occured."). Once the original error is known, it > can be decided how usocket must be fixed to map the platform specific > error to a usocket condition class and if Hunchentoot can safely > ignore this error when it occurs during an accept. Please let us know > what you find out. > > -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 hans.huebner at gmail.com Tue Mar 2 15:30:33 2010 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Tue, 2 Mar 2010 16:30:33 +0100 Subject: [hunchentoot-devel] Hunchentoot treatment of unhandled conditions In-Reply-To: <4B8D2840.4080109@itasoftware.com> References: <4B8C4016.1050604@itasoftware.com> <4B8D2840.4080109@itasoftware.com> Message-ID: On Tue, Mar 2, 2010 at 16:01, Daniel Weinreb wrote: > Hans H?bner wrote: >> I do not think that Hunchentoot should continue as if nothing happened >> when usocket:socket-accept signals an unknown condition. > > Yes, I agree.? I was thinking in terms of providing a way for > the application using Hunchentoot to have a way of > controlling what happens next in such a circumstance, > such as logging, notifying some other process, etc. I am assuming that you are still running Hunchentoot in single-threaded mode: I would wrap the call to hunchentoot:start in an appropriate error handler and process any unhandled errors as desired. If Hunchentoot does not clean up properly in such an event, I'd consider that to be a bug in Hunchentoot or usocket. Beyond that, I do not think it makes sense to special-case errors coming from usocket (i.e. file system problems can also result in conditions that Hunchentoot does not handle itself and that'd require handling by the caller). Does that make sense? If not, what exactly are you looking for? Maybe you can just send a patch that we can examine. Thanks, Hans From archimag at gmail.com Sun Mar 7 01:15:06 2010 From: archimag at gmail.com (Andrey Moskvitin) Date: Sun, 7 Mar 2010 04:15:06 +0300 Subject: [hunchentoot-devel] PATCH: simplify debugging of remote servers Message-ID: I know that for production installations, it is not advisable to have *CATCH-ERRORS-P* to be set to NIL. But it is often necessary to debug of remote server. Attached is my patch that simplifies this process. It limits the number of active calls invoke-debugger and destroys debugging threads after closing the connection with a swank-server. Andrey -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: simplify-debuggin.patch Type: application/octet-stream Size: 3765 bytes Desc: not available URL: From hans.huebner at gmail.com Sun Mar 7 07:03:35 2010 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Sun, 7 Mar 2010 08:03:35 +0100 Subject: [hunchentoot-devel] PATCH: simplify debugging of remote servers In-Reply-To: References: Message-ID: Hi Andrey, I like your patch, but can you enhance it so that it works when swank is not available? Some review comments: If you could change (find-symbol "ADD-HOOK" :swank) to something like (find-symbol (string '#:add-hook) :swank) it'd be nicer towards users of non-standard readtable case settings. We generally follow the rule to always use the most specific operator, so if you could change the LOOP in KILL-ALL-DEBUGGING-THREADS to DOLIST, it'd be more in line with the rest of the code. If you really love loop, you could remove the do from the LOOP and use the WHEN LOOP clause Thanks again, Hans On Sun, Mar 7, 2010 at 02:15, Andrey Moskvitin wrote: > I know that for production installations, it is not advisable to have > *CATCH-ERRORS-P* ?to be set to NIL. But it is often necessary to > debug of remote server. Attached is my patch that simplifies this > process. It limits the number of active calls invoke-debugger and > destroys debugging threads after closing the connection with a > swank-server. > > Andrey > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > From archimag at gmail.com Sun Mar 7 08:37:49 2010 From: archimag at gmail.com (Andrey Moskvitin) Date: Sun, 7 Mar 2010 11:37:49 +0300 Subject: [hunchentoot-devel] PATCH: simplify debugging of remote servers In-Reply-To: References: Message-ID: > I like your patch, but can you enhance it so that it works when swank > is not available? Unfortunately, swank does not modify * features *. I use to check for swank: (when (find-package: swank) ...). I added ignore-errors in case of any other swank. > If you really love loop In my code I always use iterate:) I modified the code in line with your comments. Andrey -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: simplify-debuggin.patch Type: application/octet-stream Size: 3811 bytes Desc: not available URL: From hans.huebner at gmail.com Sun Mar 7 09:02:11 2010 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Sun, 7 Mar 2010 10:02:11 +0100 Subject: [hunchentoot-devel] PATCH: simplify debugging of remote servers In-Reply-To: References: Message-ID: Andrey, I committed your patch, thank you! -Hans On Sun, Mar 7, 2010 at 09:37, Andrey Moskvitin wrote: >> I like your patch, but can you enhance it so that it works when swank >> is not available? > Unfortunately, swank does not modify * features *. I use to check > for swank: (when (find-package: swank) ...). I added ignore-errors in > case?of?any other swank. >> If you really love loop > In my code I always use iterate:) > I modified the code in line with your comments. > Andrey > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > From edi at agharta.de Sun Mar 7 10:40:18 2010 From: edi at agharta.de (Edi Weitz) Date: Sun, 7 Mar 2010 11:40:18 +0100 Subject: [hunchentoot-devel] PATCH: simplify debugging of remote servers In-Reply-To: References: Message-ID: Hi, Thanks for the patch, but please add a patch for the HTML documentation as well and add periods at the end of the docstrings. Patch guidelines are here: http://weitz.de/patches.html The HTML documentation should maybe also contain a few sentences about how this new feature is to be used. Cheers, Edi (who will be out of town until mid-March). On Sun, Mar 7, 2010 at 9:37 AM, Andrey Moskvitin wrote: >> I like your patch, but can you enhance it so that it works when swank >> is not available? > Unfortunately, swank does not modify * features *. I use to check > for swank: (when (find-package: swank) ...). I added ignore-errors in > case?of?any other swank. >> If you really love loop > In my code I always use iterate:) > I modified the code in line with your comments. > Andrey > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > From archimag at gmail.com Sun Mar 7 12:31:23 2010 From: archimag at gmail.com (Andrey Moskvitin) Date: Sun, 7 Mar 2010 12:31:23 +0000 Subject: [hunchentoot-devel] PATCH: simplify debugging of remote servers In-Reply-To: References: Message-ID: > Thanks for the patch, but please add a patch for the HTML > documentation as well and add periods at the end of the docstrings. Oh, I can write lisp-code, I can write a simple letter (via Google Translate), but for writing documentation, my English is very terrible :( I can try, but someone will have to correct me: ( Andrey -------------- next part -------------- An HTML attachment was scrubbed... URL: From hans.huebner at gmail.com Sun Mar 7 12:45:53 2010 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Sun, 7 Mar 2010 13:45:53 +0100 Subject: [hunchentoot-devel] PATCH: simplify debugging of remote servers In-Reply-To: References: Message-ID: Hi Andrey, I did not recognize your english as being bad until you wrote that it is :) The documentation needs to have information about the debug-mode-on and -off functions as well as the *max-debugging-threads* variable. You don't need to write a novel, just a description of what they do and how they're meant to be used. You should also mention that the special behavior is useful together with Slime. I'm going to review what you send and try to iron out any language issues that I find before committing. -Hans On Sun, Mar 7, 2010 at 13:31, Andrey Moskvitin wrote: >> Thanks for the patch, but please add a patch for the HTML >> documentation as well and add periods at the end of the docstrings. > Oh, I can write lisp-code, I can write a simple letter (via Google > Translate), > but for writing documentation, my English is very terrible :( I can try, > but someone?will have to correct me: ( > Andrey > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > From archimag at gmail.com Sun Mar 7 12:57:23 2010 From: archimag at gmail.com (Andrey Moskvitin) Date: Sun, 7 Mar 2010 12:57:23 +0000 Subject: [hunchentoot-devel] PATCH: simplify debugging of remote servers In-Reply-To: References: Message-ID: > I did not recognize your english as being bad until you wrote that it is :) Yes, I noticed that Google Translate has become much better over the last year :) > The documentation needs to have information about the debug-mode-on > and -off functions as well as the *max-debugging-threads* variable. Ok, I'll do it in the next few days. Andrey 2010/3/7 Hans H?bner > Hi Andrey, > > I did not recognize your english as being bad until you wrote that it is :) > > The documentation needs to have information about the debug-mode-on > and -off functions as well as the *max-debugging-threads* variable. > You don't need to write a novel, just a description of what they do > and how they're meant to be used. You should also mention that the > special behavior is useful together with Slime. I'm going to review > what you send and try to iron out any language issues that I find > before committing. > > -Hans -------------- next part -------------- An HTML attachment was scrubbed... URL: From archimag at gmail.com Tue Mar 9 11:49:17 2010 From: archimag at gmail.com (Andrey Moskvitin) Date: Tue, 9 Mar 2010 14:49:17 +0300 Subject: [hunchentoot-devel] PATCH: simplify debugging of remote servers In-Reply-To: References: Message-ID: > The documentation needs to have information about the debug-mode-on > and -off functions as well as the *max-debugging-threads* variable. I wrote this. See attachment. In addition, I attached a patch to fix typos in my code and a link to a supported me repository Hunchentoot on github.com . Andrey -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: fix-typo.patch Type: text/x-patch Size: 1155 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: improved-debug-doc.patch Type: text/x-patch Size: 2831 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: git-repo-ref.patch Type: text/x-patch Size: 632 bytes Desc: not available URL: From hans.huebner at gmail.com Tue Mar 9 16:33:28 2010 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Tue, 9 Mar 2010 17:33:28 +0100 Subject: [hunchentoot-devel] PATCH: simplify debugging of remote servers In-Reply-To: References: Message-ID: Hi Andrey, I committed your patches - after editing - to the svn repository. Cheers, Hans On Tue, Mar 9, 2010 at 12:49, Andrey Moskvitin wrote: >> The documentation needs to have information about the debug-mode-on >> and -off functions as well as the *max-debugging-threads* variable. > I wrote this. See attachment. In addition, I attached a patch to fix typos > in my code and a link to a supported me repository Hunchentoot on > github.com. > > Andrey > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > From archimag at gmail.com Tue Mar 9 19:04:49 2010 From: archimag at gmail.com (Andrey Moskvitin) Date: Tue, 9 Mar 2010 19:04:49 +0000 Subject: [hunchentoot-devel] PATCH: simplify debugging of remote servers In-Reply-To: References: Message-ID: Hi, > I committed your patches - after editing - to the svn repository. Great! Thank you very much :) Andrey -------------- next part -------------- An HTML attachment was scrubbed... URL: From zaries at global.co.za Thu Mar 18 14:23:40 2010 From: zaries at global.co.za (Phil Marneweck) Date: Thu, 18 Mar 2010 16:23:40 +0200 Subject: [hunchentoot-devel] ht-wfx (widget framework) Message-ID: <1268922220.7613.7.camel@scatha> Some time ago I suggested a simlple widget framework for hunchentoot and got a mixed bag of reaction. I have finally gotten round to creating something in that line. It is a thin layer over hunchentoot, but hopefully has enough functionality to help web development some what. Any feedback will be welcomed. http://bitbucket.org/harag/ht-wfx/wiki/Home From archimag at gmail.com Thu Mar 18 23:45:19 2010 From: archimag at gmail.com (Andrey Moskvitin) Date: Thu, 18 Mar 2010 23:45:19 +0000 Subject: [hunchentoot-devel] Probably a bug in url-encode/url-decode Message-ID: Hi, I encountered the following problem: CL-USER> (hunchentoot:url-decode "+") " " CL-USER> (hunchentoot:url-encode "+") "%2B" But in JavaScript: >>> encodeURI("+") "+" >>> decodeURI("+") "+" This is a bug? Andrey -------------- next part -------------- An HTML attachment was scrubbed... URL: From jackalmage at gmail.com Fri Mar 19 03:04:53 2010 From: jackalmage at gmail.com (Tab Atkins Jr.) Date: Thu, 18 Mar 2010 20:04:53 -0700 Subject: [hunchentoot-devel] Probably a bug in url-encode/url-decode In-Reply-To: References: Message-ID: On Thu, Mar 18, 2010 at 4:45 PM, Andrey Moskvitin wrote: > Hi, > I encountered the following problem: > CL-USER> (hunchentoot:url-decode "+") > " " > CL-USER> (hunchentoot:url-encode "+") > "%2B" > But in JavaScript: >>>> encodeURI("+") > "+" >>>> decodeURI("+") > "+" > This is a bug? > Andrey No, it just depends on which RFC you follow that describes URL escaping. For example, PHP has two different url-escaping functions to handle the two RFCs - urlencode (like hunchentoot's url-encode), and rawurlencode (like javascript's encodeURI). That said, the behavior of javascript's encode functions are generally more common. ~TJ From archimag at gmail.com Fri Mar 19 08:36:50 2010 From: archimag at gmail.com (Andrey Moskvitin) Date: Fri, 19 Mar 2010 11:36:50 +0300 Subject: [hunchentoot-devel] Probably a bug in url-encode/url-decode In-Reply-To: References: Message-ID: > No, it just depends on which RFC you follow that describes URL > escaping. Which? In JavaScript used encodeURI for URL and encodeURIComponent for single components. hunchentoot:url-decode does not match any of these functions. Browser does not replace # \+ to "%2B" in header when sending request to the server. A substitute # \ + at # \ Space, as does hunchentoot:url-decode, need for forms, but not for the url. I have wrong understanding? Andrey -------------- next part -------------- An HTML attachment was scrubbed... URL: From jordan.rhys.powell at googlemail.com Fri Mar 19 12:29:05 2010 From: jordan.rhys.powell at googlemail.com (Jordan Powell) Date: Fri, 19 Mar 2010 12:29:05 +0000 Subject: [hunchentoot-devel] Probably a bug in url-encode/url-decode In-Reply-To: References: Message-ID: <4BA36E11.4010905@googlemail.com> Try Javascript escape/unescape. There's still an issue with + but that's the only one. I tend to just use a regex replace in the Javascript to replace + with some uncommon string before sending it to the server and then doing the reverse replacement when I get the string back. For all other symbols I tried, escape/unescape matched url-encode/url-decode. Jordan On 03/19/2010 08:36 AM, Andrey Moskvitin wrote: > > No, it just depends on which RFC you follow that describes URL > > escaping. > > Which? In JavaScript used encodeURI for URL and encodeURIComponent > for single components. hunchentoot:url-decode does not match any > of these functions. Browser does not replace # \+ to "%2B" in header > when sending request to the server. A substitute # \ + at # \ Space, > as does hunchentoot:url-decode, need for forms, but not for the url. > > I have wrong understanding? > > Andrey > > > _______________________________________________ > 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 dlw at itasoftware.com Fri Mar 19 14:56:00 2010 From: dlw at itasoftware.com (Daniel Weinreb) Date: Fri, 19 Mar 2010 10:56:00 -0400 Subject: [hunchentoot-devel] Probably a bug in url-encode/url-decode In-Reply-To: References: Message-ID: <4BA39080.6020608@itasoftware.com> And for anyone who is wondering what is meant by "RFC" in this context: Tab Atkins Jr. wrote: > > > No, it just depends on which RFC you follow that describes URL > escaping. See section 2 of this document: http://www.ietf.org/rfc/rfc2396.txt - Dan > For example, PHP has two different url-escaping functions > to handle the two RFCs - urlencode (like hunchentoot's url-encode), > and rawurlencode (like javascript's encodeURI). > > That said, the behavior of javascript's encode functions are generally > more common. > > ~TJ > > _______________________________________________ > 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 archimag at gmail.com Fri Mar 19 15:15:29 2010 From: archimag at gmail.com (Andrey Moskvitin) Date: Fri, 19 Mar 2010 18:15:29 +0300 Subject: [hunchentoot-devel] Probably a bug in url-encode/url-decode In-Reply-To: <4BA39080.6020608@itasoftware.com> References: <4BA39080.6020608@itasoftware.com> Message-ID: > See section 2 of this document: > > http://www.ietf.org/rfc/rfc2396.txt Hmm, I can't find a explanation in this RFC why the function huchentoot:url-decode substitute # \+ at # \Space :( Andrey -------------- next part -------------- An HTML attachment was scrubbed... URL: From dlw at itasoftware.com Fri Mar 19 15:35:01 2010 From: dlw at itasoftware.com (Daniel Weinreb) Date: Fri, 19 Mar 2010 11:35:01 -0400 Subject: [hunchentoot-devel] Probably a bug in url-encode/url-decode In-Reply-To: References: <4BA39080.6020608@itasoftware.com> Message-ID: <4BA399A5.6000104@itasoftware.com> Sorry, actually the latest spec is http://tools.ietf.org/html/rfc3986 See also http://en.wikipedia.org/wiki/Percent-encoding Andrey Moskvitin wrote: > > See section 2 of this document: > > > > http://www.ietf.org/rfc/rfc2396.txt > > Hmm, I can't find a explanation in this RFC why the function > huchentoot:url-decode substitute # \+ at # \Space :( Yes, apparently if you put a "+" in the string that is the argument to huchentoot:url-decode, it turns into a space. However, I don't think it is legal/valid to have a "+" character in an encoded URI. Do you know of a string (call it s) such that (equalp (hunchentoot:url-decode (hunchentoot:url-encode s)) s) is false? > > Andrey > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 archimag at gmail.com Fri Mar 19 16:01:34 2010 From: archimag at gmail.com (Andrey Moskvitin) Date: Fri, 19 Mar 2010 19:01:34 +0300 Subject: [hunchentoot-devel] Probably a bug in url-encode/url-decode In-Reply-To: <4BA399A5.6000104@itasoftware.com> References: <4BA39080.6020608@itasoftware.com> <4BA399A5.6000104@itasoftware.com> Message-ID: > However, I don't think it is legal/valid to > have a "+" character in an encoded URI. However, when you type in your browser http://localhost:8080/foo+/bar+/, then (hunchentoot: request-uri *) returns "/foo+ /bar+/" (not"/foo%2B/bar%2B/" ). I specifically checked that mod_autoindex (Apache) in such cases is also not encode +. Andrey -------------- next part -------------- An HTML attachment was scrubbed... URL: From amalawi at gmail.com Mon Mar 22 18:25:32 2010 From: amalawi at gmail.com (Ala'a (cmo-0)) Date: Mon, 22 Mar 2010 22:25:32 +0400 Subject: [hunchentoot-devel] suggested imporvement: setting content-type with keywords Message-ID: Hi, Here is a patch against the stable release of hunchentoot 1.1.0. This patch will allow the API users to set the content type via keywords, for example: (setf (content-type*) :pdf) or :jpeg, :svg, :css plus the normal usage (setf (content-type*) "application/pdf") regards, Ala'a (cmo-0) -------------- next part -------------- A non-text attachment was scrubbed... Name: content-type-by-keywords.udiff Type: application/octet-stream Size: 923 bytes Desc: not available URL: From amalawi at gmail.com Mon Mar 22 22:00:22 2010 From: amalawi at gmail.com (Ala'a (cmo-0)) Date: Tue, 23 Mar 2010 02:00:22 +0400 Subject: [hunchentoot-devel] suggested imporvement: setting content-type with keywords In-Reply-To: References: Message-ID: The Same patch but with #'string-downcase removed, since the hashtable used #'equalp (thanks Zach). On 3/22/10, Ala'a (cmo-0) wrote: > Hi, > > Here is a patch against the stable release of hunchentoot 1.1.0. This > patch will allow the > API users to set the content type via keywords, for example: > > (setf (content-type*) :pdf) or :jpeg, :svg, :css > > plus the normal usage > > (setf (content-type*) "application/pdf") > > regards, > > Ala'a (cmo-0) > -- Eng. Ala'a Mohammad Alawi Private Office Of Shiek Tahnoon Bin Mohammad Al Nahyan Engineering & Maintenance Department P.O. Box 3853 Abu Dhabi, U.A.E. Tel : +971 02 6345202 Fax: +971 02 6211900, +971 02 6323932 Mobile: +971 050 8262596 -------------- next part -------------- A non-text attachment was scrubbed... Name: content-type-by-keywords-v2.udiff Type: application/octet-stream Size: 874 bytes Desc: not available URL: From hans.huebner at gmail.com Tue Mar 23 06:51:53 2010 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Tue, 23 Mar 2010 07:51:53 +0100 Subject: [hunchentoot-devel] suggested imporvement: setting content-type with keywords In-Reply-To: References: Message-ID: Hi Ala'a, thank you for your patch. I think it is useful. Can you please update a documentation update? See http://weitz.de/patches.html Thanks, Hans On Mon, Mar 22, 2010 at 23:00, Ala'a (cmo-0) wrote: > The Same patch but with #'string-downcase removed, since the hashtable > used #'equalp (thanks Zach). > > On 3/22/10, Ala'a (cmo-0) wrote: >> Hi, >> >> Here is a patch against the stable release of hunchentoot 1.1.0. This >> patch will allow the >> API users to set the content type via keywords, for example: >> >> (setf (content-type*) :pdf) ?or :jpeg, :svg, :css >> >> plus the normal usage >> >> (setf (content-type*) "application/pdf") >> >> regards, >> >> Ala'a (cmo-0) >> > > > -- > Eng. Ala'a Mohammad Alawi > Private Office Of Shiek Tahnoon Bin Mohammad Al Nahyan > Engineering & Maintenance Department > P.O. Box 3853 > Abu Dhabi, U.A.E. > Tel : +971 02 6345202 > Fax: +971 02 6211900, +971 02 6323932 > Mobile: +971 050 8262596 > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > From amalawi at gmail.com Tue Mar 23 18:56:37 2010 From: amalawi at gmail.com (Ala'a (cmo-0)) Date: Tue, 23 Mar 2010 22:56:37 +0400 Subject: [hunchentoot-devel] suggested imporvement: setting content-type with keywords In-Reply-To: References: Message-ID: Hi Hans, Please, check the attached doc patch. Regards, Ala'a (cmo-0) -------------- next part -------------- A non-text attachment was scrubbed... Name: content-type-by-keywords-doc.udiff Type: application/octet-stream Size: 634 bytes Desc: not available URL: From helmut at cybernetic-systems.de Wed Mar 24 08:45:05 2010 From: helmut at cybernetic-systems.de (helmut at cybernetic-systems.de) Date: Wed, 24 Mar 2010 09:45:05 +0100 Subject: [hunchentoot-devel] *approved-return-codes* Message-ID: <4BA9D111.5000609@cybernetic-systems.de> Is ist possible to add +http-created+ to the *approved-return-codes* list? Dojo jsonRestStore's post method requires a +http-created+, a +http-ok+ ist not enough. By default a +http-create+ returns a ' ...Created ...' string and not my json text. But I can not appaise the effects. Helmut From jpl at thoughtcrime.us Thu Mar 25 02:37:51 2010 From: jpl at thoughtcrime.us (J.P. Larocque) Date: Wed, 24 Mar 2010 19:37:51 -0700 Subject: [hunchentoot-devel] Trivial patch for potential XSS bugs Message-ID: <20100325023750.GA2249@planetarium.thoughtcrime.us> Hi, There are a few places where Hunchentoot generates HTML which directly include some strings, but the strings are plain-text and not HTML. In some cases you can see that the string can never coincidentally contain HTML or user-supplied input, so that's fine--I haven't touched these. In other cases, the string is determined from user input (at the HTTP level), so there's a danger of XSS attacks at these points. The chance of a successful attack which exploits these flaws is probably low. In any case, I think Hunchentoot should always correctly encode these user-supplied strings as HTML, since the strings are treated as plain-text and are not already formatted as HTML. A patch is attached. The changes are minimal and should speak for themselves. Thanks, -- J.P. Larocque -------------- next part -------------- A non-text attachment was scrubbed... Name: hunchentoot-1.1.0-xss_fixes.diff Type: text/x-diff Size: 2347 bytes Desc: not available URL: From vseloved at gmail.com Fri Mar 26 11:53:04 2010 From: vseloved at gmail.com (Vsevolod Dyomkin) Date: Fri, 26 Mar 2010 13:53:04 +0200 Subject: [hunchentoot-devel] How to properly write directly to output stream? Message-ID: <89dc7c5b1003260453x168fc744q96ce53aca4e70ac5@mail.gmail.com> Hi, I'm developing a new web-application, based on Hunchentoot 1.1, my previous ones were based on pre-1.0 version. Since there was a switch to binary-streams, the following approach to HTML generation directly to the input stream from CL-WHO, which I'd used previously had to be modified from (let ((out (send-headers))) (with-html-output (*who-stream* out) ;; ... to (let ((out (flex:make-flexi-stream (send-headers) :external-format *hunchentoot-default-external-format* :element-type 'character))) (with-html-output (*who-stream* out) ;; ... Still it doesn't perform the same as before, because, as far as I understand, of the new handling of chunking. It seems to me, that the chunk size is set to 8K in Chunga and in my case that's very inconvenient: I'd like to serve the page in many small portions, as the time of their "arrival" is quite unpredictable. That is why I've tried to turn off chunking or set lower chunk sizes (1K, for example) via both the public API (acceptor-output-chunking-p) and by manipulating the Hunchentoot internals, but failed to achieve anything. Either only the headers are sent and the connection is closed, or I need to wait until the handler returns. I would be grateful, if someone, who better understands the internal mechanisms of that, gave me an explanation and some advice. Thanks in advance, Vsevolod Dyomkin -------------- next part -------------- An HTML attachment was scrubbed... URL: From edi at agharta.de Tue Mar 30 12:29:20 2010 From: edi at agharta.de (Edi Weitz) Date: Tue, 30 Mar 2010 14:29:20 +0200 Subject: [hunchentoot-devel] *approved-return-codes* In-Reply-To: <4BA9D111.5000609@cybernetic-systems.de> References: <4BA9D111.5000609@cybernetic-systems.de> Message-ID: That should not be a problem. You use *approved-return-codes* and/or *handle-http-errors-p* simply to determine what Hunchentoot should do automatically. On Wed, Mar 24, 2010 at 9:45 AM, wrote: > Is ist possible to add +http-created+ to the > *approved-return-codes* list? > > Dojo jsonRestStore's post method requires a +http-created+, > a +http-ok+ ist not enough. > By default a +http-create+ returns a ' ...Created ...' string > and not my json text. > > But I can not appaise the effects. > > Helmut > > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > > From edi at agharta.de Tue Mar 30 13:03:55 2010 From: edi at agharta.de (Edi Weitz) Date: Tue, 30 Mar 2010 15:03:55 +0200 Subject: [hunchentoot-devel] How to properly write directly to output stream? In-Reply-To: <89dc7c5b1003260453x168fc744q96ce53aca4e70ac5@mail.gmail.com> References: <89dc7c5b1003260453x168fc744q96ce53aca4e70ac5@mail.gmail.com> Message-ID: I don't fully understand what you are trying to achieve when you are saying that you have to wait until the handler returns. That is something you have to do anyway. As for the chunk size, note that this might also be governed by a) the underlying stream provided by your Lisp implementation and b) the client. Edi. On Fri, Mar 26, 2010 at 12:53 PM, Vsevolod Dyomkin wrote: > Hi, > I'm developing a new web-application, based on Hunchentoot 1.1, my previous > ones were based on pre-1.0 version. ?Since there was a switch to > binary-streams, the following approach to HTML generation directly to the > input stream from CL-WHO, which I'd used previously had to be modified from > (let ((out (send-headers))) > ?? (with-html-output (*who-stream* out) > ?? ? ?;; ... > to > (let ((out (flex:make-flexi-stream?(send-headers) > ?? ? ? ? ? ? ? ? ? ? ? ? :external-format > *hunchentoot-default-external-format* > ?? ? ? ? ? ? ? ? ? ? ? ? :element-type 'character))) > ?? (with-html-output (*who-stream* out) > ?? ? ?;; ... > Still it doesn't perform the same as before, because, as far as I > understand, of the new handling of chunking. It seems to me, that the chunk > size is set to 8K in Chunga and in my case that's very inconvenient: I'd > like to serve the page in many small portions, as the time of their > "arrival" is quite unpredictable. > That is why I've tried to turn off chunking or set lower chunk sizes (1K, > for example) via both the public API (acceptor-output-chunking-p) and by > manipulating the Hunchentoot internals, but failed to achieve anything. > Either only the headers are sent and the connection is closed, or I need to > wait until the handler returns. > I would be grateful, if someone, who better understands the internal > mechanisms of that, gave me an explanation and some advice. > Thanks in advance, > Vsevolod Dyomkin > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > From edi at agharta.de Tue Mar 30 13:06:56 2010 From: edi at agharta.de (Edi Weitz) Date: Tue, 30 Mar 2010 15:06:56 +0200 Subject: [hunchentoot-devel] Trivial patch for potential XSS bugs In-Reply-To: <20100325023750.GA2249@planetarium.thoughtcrime.us> References: <20100325023750.GA2249@planetarium.thoughtcrime.us> Message-ID: Thanks, patch applied. On Thu, Mar 25, 2010 at 3:37 AM, J.P. Larocque wrote: > Hi, > > There are a few places where Hunchentoot generates HTML which directly > include some strings, but the strings are plain-text and not HTML. ?In > some cases you can see that the string can never coincidentally > contain HTML or user-supplied input, so that's fine--I haven't touched > these. ?In other cases, the string is determined from user input (at > the HTTP level), so there's a danger of XSS attacks at these points. > > The chance of a successful attack which exploits these flaws is > probably low. ?In any case, I think Hunchentoot should always > correctly encode these user-supplied strings as HTML, since the > strings are treated as plain-text and are not already formatted as > HTML. > > A patch is attached. ?The changes are minimal and should speak for > themselves. > > Thanks, > > -- > J.P. Larocque > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > From _deepfire at feelingofgreen.ru Tue Mar 30 21:39:08 2010 From: _deepfire at feelingofgreen.ru (Samium Gromoff) Date: Wed, 31 Mar 2010 01:39:08 +0400 Subject: [hunchentoot-devel] How to properly write directly to output stream? In-Reply-To: <89dc7c5b1003260453x168fc744q96ce53aca4e70ac5@mail.gmail.com> References: <89dc7c5b1003260453x168fc744q96ce53aca4e70ac5@mail.gmail.com> Message-ID: <8739zhcww3.fsf@auriga.deep> On Fri, 26 Mar 2010 13:53:04 +0200, Vsevolod Dyomkin wrote: > Hi, > > I'm developing a new web-application, based on Hunchentoot 1.1, my previous > ones were based on pre-1.0 version. Since there was a switch to > binary-streams, the following approach to HTML generation directly to the > input stream from CL-WHO, which I'd used previously had to be modified from > > (let ((out (send-headers))) > (with-html-output (*who-stream* out) > ;; ... > > to > > (let ((out (flex:make-flexi-stream (send-headers) > :external-format > *hunchentoot-default-external-format* > :element-type 'character))) > (with-html-output (*who-stream* out) > ;; ... > > Still it doesn't perform the same as before, because, as far as I > understand, of the new handling of chunking. It seems to me, that the chunk > size is set to 8K in Chunga and in my case that's very inconvenient: I'd > like to serve the page in many small portions, as the time of their > "arrival" is quite unpredictable. > > That is why I've tried to turn off chunking or set lower chunk sizes (1K, > for example) via both the public API (acceptor-output-chunking-p) and by > manipulating the Hunchentoot internals, but failed to achieve anything. > Either only the headers are sent and the connection is closed, or I need to > wait until the handler returns. Do you look for HUNCHENTOOT:SEND-HEADERS, per chance? [Function] send-headers => stream Sends the initial status line and all headers as determined by the REPLY object *REPLY*. Returns a binary stream to which the body of the reply can be written. Once this function has been called, further changes to *REPLY* don't have any effect. Also, automatic handling of errors (i.e. sending the corresponding status code to the browser, etc.) is turned off for this request and functions like REDIRECT or to ABORT-REQUEST-HANDLER won't have the desired effect once the headers are sent. If your handlers return the full body as a string or as an array of octets, you should not call this function. If a handler calls SEND-HEADERS , its return value is ignored.