Pull requests with bug fixes are most welcome, of course :)
Also, I've noticed in some documentation strings two spaces inbetween sentences but in some documentation strings - one space. How to deal with it?
I regularly put two spaces after a dot, but I think it is wrong. Maybe you can find an authoritative answer what's right and then make the docstrings be correct.
Wikipedia says there is no "right" thing. Given that, two spaces behind a dot should be just fine.
Well, I'll fix one space to two?
My "authoritative" answer is follow the convention of HyperSpec - "one space after the dot", or follow the convention of Hunchentoot - "two spaces", but not both at the same time. :-)
If you want to fix the issue, you get to decide in which direction you're fixing it.
I won't reject a pull request if you decide that one space is right.
I assume I can use hunchentoot to just consume a web service? Are there any tutorials available for that, or can something "less heavy" than hunchentoot be used?
Hunchentoot is a http server. A web service is "consumed" by a client like Drakma.
thanks for the clarification, I'll continue to look for some examples of Drakma consuming a restful web service.
Can hunchentoot accept fastcgi connections?
No, hunchentoot is a standalone http server. It does not support fastcgi or other non-http frontend integrations.
Hi, I'm trying to use drakma to upload (music) files to a hunchentoot server, and I'm finding that when the filename contains non-ascii characters POST-PARAMETER returns NIL. I assume I'm doing something
Is it possible to do parameterized routes with hunchentoot?
Hello everyone, I joined this chat because of the same question. @thiru did you or someone else found a way to define an easy handler with a parameterized or wildcarded url? I want to define an uri for DELETE/GET actions: /api/blogposts/[id]
easy-handlers do not directly support parametrized routes, but as the URI argument can be a function, you can call your routing function there.
So the answer is "there is a way, but you need to write supporting code".
@pjstirling It is probably too late, but my guess is that you have a character encoding problem. Does the problem occur with the hunchentoot-test server as well?
Thanks for your answer. That is everything I needed to know, to implement it!
@BurkeB I went the function route originally but I found directly manipulating *dispatch-table* easier:
And you can also use create-folder-dispatcher-and-handler for folders containing static files (in place of create-regex-dispatcher)
@thiru that looks like an elegant way. In my case I probably use "push" to add these regex dispatchers, to keep the "dispatch-easy-handlers", for my few easy-handlers with a static :uri argument (no static files, just static endpoints).
hi, I was wondering what are others solutions to handling a 'HASH-TABLE parameter in which one of the fields is a SELECT MULTIPLE element with multiple options selected. Currently Hunchentoot just put one value there, were I was hoping to get an array of the selected options. I have a hack by post-processing the HASH-TABLE generated and fixing the appropriate keys using POST-PARAMETER. But it does seem that there could be a better way.
Hello, for my site I need to limit the amount of time spent in answering a request. There is some way to do it in general? or at least for a particular handler? I was thinking of calling a function in a new thread at the beginning of the work, passing to it the current thread and/or acceptor or request. Then after a sleep for a certain time, the function should interrupt the current request processing, if still alive. There is something simple that can be done to do this? Or a better approach? Thanks.
R.M. Miller Jr.
@SneakyDave@SneakyDave I was under the inpression that Hutchentoot was one of the, if not ' the ', lightest webserver out there. Sorry for any speculative tone I may deliver, but, were you just not aware of the Hutchentoots purpouse, or am I the one out of the loop here? Is it suppose to be something else?I've only ben using this locally. Hutchentoot as of now, feels like its a product truley worth exploring and learning any abstraction it may contain. Something as well written deserves a developer community who would impliment this for all its worth, and I believe that was one of the shared ideals amung the authors. This being a somewhat opposite aproach to webservers like Apache, NGINX, or any other large scale endevore.
Has anyone been able to run hutchentoot on CLISP/OSX? I'm having all sorts of trouble installing the dependencies. Finally I ran into a brick wall with this message: "CFFI requires CLISP compiled with dynamic FFI support" which apparently is not possible to overcome with CLISP. Any tips? Thanks for the help.
@protoncito yes, but it was long time ago. I remember that I started it without any problems.
@dfigrishin I really cannot understand you. Lisp is lisp, c++ is c++
Symbol "START-SERVER" not found in the HUNCHENTOOT package Any clues? Trying to build a basic photo gallery /ecommerce app in common lisp
Abu Hussain Al-Mukhtar
Hi everyone, my name is Raymundo, and I am rather trying to develop a web app via Hunchentoot
I am sorry to bother all of you with this kind of newbie stuff, but I have read through the whole reference manual at quickref and spent more than a couple of hours in the homepage as well....and I still can't figure out where to start to be able to implement user sessions. Let's start with the basics: I don't really get how to read or modify the session-db. To make it clear: all I want is user authentication, which would enable me to work with sessions in general (I am using Postmodern as a user/pass database)
Documentation states that hunchentoot implements session handling automatically...but just how can/should I access session data?
You can invoke (setf (hunchentoot:session-value :foo) 1) to set and (hunchentoot:session-value :foo) to retrieve a session value named :foo
Hi Hans, thank you for your answer. There is one step I am missing though. If I try to setf (huchentoot:session-value :client) 1), I get the error The variable HUNCHENTOOT:REQUEST is unbound. I am using the easy-ssl-acceptor
Abu Hussain Al-Mukhtar
Hi everyone! I'm coming across a rather amusing (if you look at it the positive way) situation. If, inside a <form> element, I use an :input :type "number" in CL-Who to send a Post request to a Hunchentoot easy handler, and I specify the enctype to "multipart/form-data", then the integers I can play around with in my web site are stored as arrays. Working with them makes my life unnecessarily complicated, I just want to parse them as an integer which they are. Has any of you had a similar experience? what would you recommend to get around this situation? Thanks in advance
My ultimate goal is to feed that integer to a loop so I can generate an X number of buttons for the user
Abu Hussain Al-Mukhtar
In other words, why work with arrays if there is a possibility to parse those numbers as integers in the first place
Abu Hussain Al-Mukhtar
Hello everyone! I was wondering if there is a possibility to store all the checked checkboxes in an array? Right now I am having trouble with that: I can have as many checkboxes as I want, but only the first hit gets actually parsed and stored in a lexical variable. Is there a way around this? e.g. In the group containing the checkboxes "espresso", "cold brew" and "tonic", store all three in the variable drink, not only "espresso"