tbnl-devel January 2009

tbnl-devel@common-lisp.net

17 participants
11 discussions

[hunchentoot-devel] Maximum Request Size
by Volkan YAZICI 01 Feb '09

01 Feb '09

Hi, Here are two patches[1][2] for both flexi-streams and hunchentoot. First patch makes flexi-streams to signal a condition when stream BOUND gets exceeded -- documentation and tests are included. Second one uses freshly introduced flexi-streams feature to limit the maximum request size. The latter hunchentoot patch is not well tested, doesn't include any documentation, replaces (raw-post-data ...) call with (clear-input ...) to flush the input stream (thus, can have chunking and common lisp implementation/platform related problems). It appears to be working for me, I hope it would for you as well. Thanks Hans Huebner for his kindly helps and Edi Weitz for his uninterest in any effort. Regards. P.S. Enhancements are patched against the repositories located at http://bknr.net/svn/ediware address. [1] http://www.students.itu.edu.tr/~yazicivo/tmp/flexi-streams-bound-invalidati… [2] http://www.students.itu.edu.tr/~yazicivo/tmp/hunchentoot-request-size-limit…

10 18

[hunchentoot-devel] Is there any implementation of XML-RPC for Hunchentoot
by christoph.senjak＠web.de 30 Jan '09

30 Jan '09

Hello. Again a question. Is there already any Implementation of XML-RPC running on Hunchentoot. I only found S-XML-RPC so far, and it seems like it is using allegro serve. It may not be too hard to implement, but if it is already there, I dont want to do it. Greetings Christoph-Simon Senjak

2 2

[hunchentoot-devel] rfc2388: Handling of octets and strings is flawed
by Leslie P. Polzer 30 Jan '09

30 Jan '09

rfc2388 doesn't care about the encoding of strings despite of returning them. The result of a parsed body that doesn't contain binary data is then a vector of octets disguised as string, forcing the ultimate user to jump through this or a similar hoop: (sb-ext:octets-to-string (map '(vector (unsigned-byte 8)) #'char-int s)) Hunchentoot for example will just return this broken string when rfc2388 is used for parsing a parameter's content. IMO parse-mime should return a vector of octets and not a string. Its users (e.g. HT) should then apply appropriate character conversion functions to build a proper string. Leslie -- LinkedIn Profile: http://www.linkedin.com/in/polzer Xing Profile: https://www.xing.com/profile/LeslieP_Polzer Blog: http://blog.viridian-project.de/

2 3

[hunchentoot-devel] Changes in (send-headers) ?
by css 28 Jan '09

28 Jan '09

Hello. I havent used hunchentoot for a while now, so I checked out the svn-repository on http://bknr.net/svn/ediware/ (I hope this is the correct one) and Installed the packages. The server seems to work, but unfortunately, the following code seems not to do: (defun http-seite () (with-html-output (out (send-headers)) (:html (:head (:title "Hallo-Welt-Seite")) (:body (:h1 "Hallo Welt"))))) (setf *dispatch-table* (list (create-prefix-dispatcher "/hallo-welt" 'http-seite))) (defvar *server* (start-server :port 8000)) When calling http://localhost:8000/hallo-welt, I only get an empty page. For any other URL, i get a "not found" error. When defining the function differently, returning a string, say (defun http-seite () (with-html-output-to-string (bla) (:html (:head (:title "Hallo-Welt-Seite")) (:body (:h1 "Hallo Welt"))))) the whole thing works. Also the more trivial functions (defun http-2 () (write-char #\A (send-headers))) and (defun http-2 () (write-char #\A (send-headers)) (finish-output (send-headers))) do not produce any output. I read the included documentation, but it seems like (send-headers) hasnt changed its meening according to it, and also the code doesnt say anything else. Any Ideas what I could be doing wrong? Greetings Christoph

4 3

[hunchentoot-devel] CLEAR-INPUT and RAW-POST-DATA
by Volkan YAZICI 21 Jan '09

21 Jan '09

Hi, Why doesn't we use (clear-input *hunchentoot-stream*) instead of (raw-post-data :force-binary t) in the START-OUTPUT function in headers.lisp? Regards.

1 0

Re: [hunchentoot-devel] Widget Guidlines
by First name Last name 20 Jan '09

20 Jan '09

>> Hi >> I have been using hunchentoot for the last two months and I have created a >> DB-Grid widget for myself. I pass relevant info in through parameters like >> table name and columns to display and the widget generates a html grid with >> paging, edit/delete and search functionality. >Hi, >I believe that attempt for such standardization could be weblocks >(based on hunchentoot)... >http://weblocks.viridian-project.de/ >Best regards, >Tomek Lipski Tomek I think weblocks is a bit of a over kill. I have never used it but from what I saw in the documentation it is big and in my opinion might carry to much over head. I am sure it has its right full place but I am not sure this is it. What I was thinking about was free standing widgets that don't need a whole framework to carry them. A specification for something like this would include a list of common properties/functionality and general methodology (persistence,state...etc) that would fit in with hunchentoot's design and strong points. Regards Phil PS. Apologies for re-posting but I am still getting the hang of using the mailing list....for some reason the previous post lost the text (think it is because my web client wraps replies in table)

4 4

Re: [hunchentoot-devel] Widget Guidlines
by First name Last name 20 Jan '09

20 Jan '09

----- Original Message ------ From:Tomasz Lipski Sent:Tuesday, January 20, 2009 10:26 To:General interest list for Hunchentoot and CL-WEBDAV tbnl-devel(a)common-lisp.net; Subject:Re: [hunchentoot-devel] Widget Guidlines 2009/1/19 First name Last name : >> Hi >> I have been using hunchentoot for the last two months and I have created a >> DB-Grid widget for myself. I pass relevant info in through parameters like >> table name and columns to display and the widget generates a html grid with >> paging, edit/delete and search functionality. >Hi, >I believe that attempt for such standardization could be weblocks >(based on hunchentoot)... >http://weblocks.viridian-project.de/ >Best regards, >Tomek Lipski Tomek I think weblocks is a bit of a over kill. I have never used it but from what I saw in the documentation it is big and in my opinion might carry to much over head. I am sure it has its right full place but I am not sure this is it. What I was thinking about was free standing widgets that don't need a whole framework to carry them. A specification for something like this would include a list of common properties/functionality and general methadoligy (persistance,state...etc) that would fit in with hunchentoot's design and strong points. Regards Phil

1 0

Re: [hunchentoot-devel] Widget Guidlines
by First name Last name 20 Jan '09

20 Jan '09

I don't think we need agreement from all, we need one or two of the main developers to agree on a specification. Compliance can be enforced by only adding "valid" widgets to a widgets repository. As more widgets are added arguments about the the how and why will fade as reusability wins in the end. Besides its open source, and opponents can come up with their own specification and own repository if they feel that strongly about it, nothing wrong with some choice. The specification does not need to be perfect if it covers 80% of what is needed then it will be good enough. The last 20% is almost always not worth bothering with any way. I vote for some thing over nothing here. ----- Original Message ------ From:Edi Weitz Sent:Tuesday, January 20, 2009 09:08 To:General interest list for Hunchentoot and CL-WEBDAV tbnl-devel(a)common-lisp.net; Subject:Re: [hunchentoot-devel] Widget Guidlines On Mon, Jan 19, 2009 at 7:41 PM, First name Last name wrote: > I have been using hunchentoot for the last two months and I have created a > DB-Grid widget for myself. I pass relevant info in through parameters like > table name and columns to display and the widget generates a html grid with > paging, edit/delete and search functionality. > > My lisp experience however is limited and my widget is feeling more and more > clunky as the functionality grows. I would like to ask the experts how they > would structure/design such a widget using hunchentoot (cl-who + > postmodern). > > I was thinking that such a widget might benefit others as well and others > might have widgets that I might find useful. If we all use our own designs > thow the resulting code might end up being to diverse to support. I would > also not like to have to use a whole other framework on top of hunchentoot > unless it came from the hunchentoot community and/or was supported by them. > I would like the widgets to be as close as possible to hunchentoot to make > them small, light and independant. > > Would it be feasible to set up a guideline/specification for hunchentoot > widgets in general and widgets dealing with data-binding specifically? This > way we could share widget among each other based on some standard that is > documented and "trusted". I think this generally sounds like a good idea although I imagine that it'll be kind of hard to reach consensus even in the small group of Hunchentoot users about the requirements for such widgets. Cheers, Edi. _______________________________________________ tbnl-devel site list tbnl-devel(a)common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel

1 0

[hunchentoot-devel] Widget Guidlines
by First name Last name 20 Jan '09

20 Jan '09

Hi I have been using hunchentoot for the last two months and I have created a DB-Grid widget for myself. I pass relevant info in through parameters like table name and columns to display and the widget generates a html grid with paging, edit/delete and search functionality. My lisp experience however is limited and my widget is feeling more and more clunky as the functionality grows. I would like to ask the experts how they would structure/design such a widget using hunchentoot (cl-who + postmodern). I was thinking that such a widget might benefit others as well and others might have widgets that I might find useful. If we all use our own designs thow the resulting code might end up being to diverse to support. I would also not like to have to use a whole other framework on top of hunchentoot unless it came from the hunchentoot community and/or was supported by them. I would like the widgets to be as close as possible to hunchentoot to make them small, light and independant. Would it be feasible to set up a guideline/specification for hunchentoot widgets in general and widgets dealing with data-binding specifically? This way we could share widget among each other based on some standard that is documented and "trusted". Regards

4 3

[hunchentoot-devel] Fwd: [Sbcl-devel] SBCL crashes in READ-SEQUENCE with Error: The value 1025 is not of type (MOD 1025)
by Hans Hübner 08 Jan '09

08 Jan '09

Recently, I saw one of my servers crash to ldb with the error message "Error: The value 1025 is not of type (MOD 1025)". This happens every few months, and I have not been bothered too much by it (and I will be bothered even less now that Zach Beane has posted how I can disable ldb), but I wanted to know what the cause for this is, so inquired in sbcl-devel. See Juho's answer below. It boils down to: There is a file descriptor leak. -Hans ---------- Forwarded message ---------- From: Juho Snellman <jsnell(a)iki.fi> Date: Thu, Jan 8, 2009 at 14:26 Subject: Re: [Sbcl-devel] SBCL crashes in READ-SEQUENCE with Error: The value 1025 is not of type (MOD 1025) To: Hans Hübner <hans.huebner(a)gmail.com> Cc: sbcl-devel(a)lists.sourceforge.net Hans Hübner <hans.huebner(a)gmail.com> writes: > Hi, > > sporadically, some of my Hunchentoot based web servers running on SBCL > 1.0.20.22 (FreeBSD, threaded) crash to ldb, with the following messages > appearing on the REPL: > > Error: The value 1025 is not of type (MOD 1025). My first guess would be that you've got a fd that's too large (select can only handle fds smaller than FD_SETSIZE). Some people have explored replacing the use of select() for serve-event with using various other fd polling interfaces to work around this problem (there should be one patch floating around that uses epoll() on Linux, don't know whether that'd be usable for you on FreeBSD). -- Juho Snellman

2 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

tbnl-devel January 2009