[tbnl-devel] PATH_INFO
Hello, Is it possible to get the path info with TBNL? I couldn't find it in the manual. Thanks! -- '(Yours parenthetically), peter barabas. ((call/cc call/cc) (call/cc call/cc))
On Thu, 6 Oct 2005 10:02:57 +0200, Peter BARABAS <peter.barabas@gmail.com> wrote:
Is it possible to get the path info with TBNL? I couldn't find it in the manual.
What is the path info? Do you mean this? <http://weitz.de/tbnl/#script-name>
On 10/6/05, Edi Weitz <edi@agharta.de> wrote:
On Thu, 6 Oct 2005 10:02:57 +0200, Peter BARABAS <peter.barabas@gmail.com> wrote:
Is it possible to get the path info with TBNL? I couldn't find it in the manual.
What is the path info? Do you mean this?
As far as I know they are different things. If PATH_INFO exists, it's the next after SCRIPT_NAME. It's something like: http://www.unknown.net/script.cgi/path_info. -- '(Yours parenthetically), peter barabas. ((call/cc call/cc) (call/cc call/cc))
On Thu, 6 Oct 2005 20:17:55 +0200, Peter BARABAS <peter.barabas@gmail.com> wrote:
As far as I know they are different things. If PATH_INFO exists, it's the next after SCRIPT_NAME. It's something like: http://www.unknown.net/script.cgi/path_info.
OK, I've googled around a bit and to me it looks like PATH_INFO only makes sense for file-based web services. How would you define the value of PATH_INFO for an arbitrary TBNL request?
On 10/6/05, Edi Weitz <edi@agharta.de> wrote:
On Thu, 6 Oct 2005 20:17:55 +0200, Peter BARABAS <peter.barabas@gmail.com> wrote:
As far as I know they are different things. If PATH_INFO exists, it's the next after SCRIPT_NAME. It's something like: http://www.unknown.net/script.cgi/path_info.
OK, I've googled around a bit and to me it looks like PATH_INFO only makes sense for file-based web services. How would you define the value of PATH_INFO for an arbitrary TBNL request?
I don't know if it makes sense, but I'd treat the prefix dispatch part as SCRIPT_NAME and everything after it as PATH_INFO. E.g. in http://www.something.net/authors/Kurt_Vonnegut "/authors/" would be the SCRIPT_NAME and "Kurt_Vonnegut" the PATH_INFO. Again, this might be non-sense. -- '(Yours parenthetically), peter barabas. ((call/cc call/cc) (call/cc call/cc))
On Fri, 7 Oct 2005 11:04:26 +0200, Peter BARABAS <peter.barabas@gmail.com> wrote:
I don't know if it makes sense, but I'd treat the prefix dispatch part as SCRIPT_NAME and everything after it as PATH_INFO. E.g. in http://www.something.net/authors/Kurt_Vonnegut "/authors/" would be the SCRIPT_NAME and "Kurt_Vonnegut" the PATH_INFO. Again, this might be non-sense.
Yes, that would make sense with prefix dispatchers but not with arbitrary dispatchers. What if the dispatcher dispatches depending on the last three characters of the URI? Or depending on the phase of the moon? I think what you want can be achieved if you, in your own dispatcher, set AUX-REQUEST-VALUE to whatever information about the URI you want to communicate to the handlers. Only the dispatcher can know which part of the URI is relevant to the handler and which isn't. On a related note, I agree that SCRIPT-NAME might not be the best name but at the moment it's at least well-defined. Cheers, Edi.
Hi, Sorry I'm in a rush out the door, shouldn't really be writing this now... Is this what you had in mind Peter... I agree with Edi about not making sense in the general case, but that there is a really really common case, and that's where you are using a prefix to dispatch (maybe Java's influence, maybe just because it makes for useful URLs?) anyway... I've take two approaches to how this works, currently using TBNL, I've been writing things like: (let ((command (cdddr (split-sequence:split-sequence #\/ (script- name)))))... in the handler. This is a bit ugly because you have to count the 'd's in your cd*r -- but I note that the dispatch prefix is not always the same as the command prefix (dispatch prefixes can take a minimalist approach, only specify the minimum needed) so the handler had to do some work or know something anyway. (btw, I used the word 'command', Peter used 'PATH_INFO' -- I don't really like either :-) Anyway, if you do this then you have a list of strings. Handy. In a much larger Java application this was far too limiting. I wrote a dispatching system that allowed the programmer to name parts of the URL in the regex used to dispatch. The named parts were then turned into parameter like things. Sooner or later I'm going to have to write this in lisp. Cheers, Bob On Oct 7, 2005, at 5:19 AM, Edi Weitz wrote:
On Fri, 7 Oct 2005 11:04:26 +0200, Peter BARABAS <peter.barabas@gmail.com> wrote:
I don't know if it makes sense, but I'd treat the prefix dispatch part as SCRIPT_NAME and everything after it as PATH_INFO. E.g. in http://www.something.net/authors/Kurt_Vonnegut "/authors/" would be the SCRIPT_NAME and "Kurt_Vonnegut" the PATH_INFO. Again, this might be non-sense.
Yes, that would make sense with prefix dispatchers but not with arbitrary dispatchers. What if the dispatcher dispatches depending on the last three characters of the URI? Or depending on the phase of the moon?
I think what you want can be achieved if you, in your own dispatcher, set AUX-REQUEST-VALUE to whatever information about the URI you want to communicate to the handlers. Only the dispatcher can know which part of the URI is relevant to the handler and which isn't.
On a related note, I agree that SCRIPT-NAME might not be the best name but at the moment it's at least well-defined.
Cheers, Edi. _______________________________________________ tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
---- Bob Hutchison -- blogs at <http://www.recursive.ca/hutch/> Recursive Design Inc. -- <http://www.recursive.ca/> Raconteur -- <http://www.raconteur.info/>
Il giorno ven, 07/10/2005 alle 11.04 +0200, Peter BARABAS ha scritto:
OE.g. in http://www.something.net/authors/Kurt_Vonnegut "/authors/" would be the SCRIPT_NAME and "Kurt_Vonnegut" the PATH_INFO.
You could use create-groups-bind-regex-dispatcher, a macro I wrote just for this pourpose: extracting parameters from URLs. See the contrib/ directory, and the README file. In short, you could append this to your *dispatch-table* (untested, the regex may be wrong :-): (create-groups-bind-regex-dispatcher "^\\/authors\\/([^\\/])$" (author) authors-dispatch-fn) And a dispatch-fn like this, that will take the author out of the URL as a keyword argument: (defun authors-dispatch-fn (&key author) (do-stuff author)) You could (well, should) also url-decode the argument before passing it to the dispatch-fn: (create-groups-bind-regex-dispatcher "^\\/authors\\/([^\\/])$" ((url-decode author)) authors-dispatch-fn) Regards, alceste -- Alceste Scalas <alceste.scalas@gmx.net>
On Oct 8, 2005, at 3:52 AM, Alceste Scalas wrote:
Il giorno ven, 07/10/2005 alle 11.04 +0200, Peter BARABAS ha scritto:
OE.g. in http://www.something.net/authors/Kurt_Vonnegut "/authors/" would be the SCRIPT_NAME and "Kurt_Vonnegut" the PATH_INFO.
You could use create-groups-bind-regex-dispatcher, a macro I wrote just for this pourpose: extracting parameters from URLs. See the contrib/ directory, and the README file.
Oh, that's perfect for me. Thanks! With any luck the OP can use it too. Cheers, Bob
participants (4)
-
Alceste Scalas -
Bob Hutchison -
Edi Weitz -
Peter BARABAS