From olegsivokon at gmail.com  Wed Jul  6 11:41:50 2011
From: olegsivokon at gmail.com (Oleg Sivokon)
Date: Wed, 6 Jul 2011 14:41:50 +0300
Subject: [hunchentoot-devel] Timing out when reading long post requests?
Message-ID: <CAJQBtgn_PG2vsg9NhT7sXV6Yc6pU7rUMwx5P0-8PjHt2etWN+w@mail.gmail.com>

Hello, I'm not sure what is causing this error (please see the stack trace
below), all I can say it's relatively big XML being sent. I must be doing
something tremendously inefficient or else this error means something else,
but I hope you would be able to advise:

[2011-07-06 14:20:27 [ERROR]] I/O timeout reading #<SB-SYS:FD-STREAM for "a
socket" {B8E0AA1}>.
0: (SB-DEBUG::MAP-BACKTRACE #<CLOSURE (LAMBDA #) {B9034D5}>)[:EXTERNAL]
1: (BACKTRACE 536870911 #<SB-IMPL::STRING-OUTPUT-STREAM {B903471}>)
2: (TRIVIAL-BACKTRACE:PRINT-BACKTRACE-TO-STREAM
    #<SB-IMPL::STRING-OUTPUT-STREAM {B903471}>)
3: (HUNCHENTOOT::GET-BACKTRACE)
4: ((FLET #:LAMBDA284) #<SB-SYS:IO-TIMEOUT {B903139}>)
5: (SIGNAL #<SB-SYS:IO-TIMEOUT {B903139}>)[:EXTERNAL]
6: (ERROR SB-SYS:IO-TIMEOUT)[:EXTERNAL]
7: (SB-IMPL::SIGNAL-TIMEOUT SB-SYS:IO-TIMEOUT)[:EXTERNAL]
8: (SB-IMPL::REFILL-INPUT-BUFFER #<SB-SYS:FD-STREAM for "a socket"
{B8E0AA1}>)
9: (SB-IMPL::FD-STREAM-READ-N-BYTES
    #<SB-SYS:FD-STREAM for "a socket" {B8E0AA1}>
    #(97 108 121 116 105 99 115 62 10 32 32 102 49 50 51 52 53 54 55 56 57
48
. . . long array of data
)
    0
    8191
    NIL)
10: (SB-IMPL::ANSI-STREAM-READ-SEQUENCE
     #(97 108 121 116 105 99 115 62 10 32 32 102 49 50 51 52 53 54 55 56 57
48
. . . long array of data
)
     #<SB-SYS:FD-STREAM for "a socket" {B8E0AA1}>
     0
     8191)
11: (READ-SEQUENCE
     #(97 108 121 116 105 99 115 62 10 32 32 102 49 50 51 52 53 54 55 56 57
48
. . . long array of data
)
     #<SB-SYS:FD-STREAM for "a socket" {B8E0AA1}>)[:EXTERNAL]
12: ((SB-PCL::FAST-METHOD TRIVIAL-GRAY-STREAMS:STREAM-READ-SEQUENCE
      (FLEXI-STREAMS:FLEXI-INPUT-STREAM T T T))
     #<unavailable argument>
     #<unavailable argument>
     #<unavailable argument>
     #<unavailable argument>
     #<unavailable argument>
     #<unavailable argument>)[:EXTERNAL]
13: ((LAMBDA
         (SB-PCL::.PV. SB-PCL::.NEXT-METHOD-CALL. SB-PCL::.ARG0.
SB-PCL::.ARG1.
          SB-PCL::.ARG2. SB-PCL::.ARG3. SB-INT:&MORE
          SB-PCL::.DFUN-MORE-CONTEXT. SB-PCL::.DFUN-MORE-COUNT.))
     #<unused argument>
     #<unused argument>
     #<FLEXI-STREAMS:FLEXI-IO-STREAM {B8EA781}>
     #(97 108 121 116 105 99 115 62 10 32 32 102 49 50 51 52 53 54 55 56 57
48
. . . long array of data
)
     0
     8191
     -307111303
     0)
14: (READ-SEQUENCE
     #(97 108 121 116 105 99 115 62 10 32 32 102 49 50 51 52 53 54 55 56 57
48
. . . long array of data
)
     #<FLEXI-STREAMS:FLEXI-IO-STREAM {B8EA781}>)[:EXTERNAL]
15: ((SB-PCL::FAST-METHOD RUNES::XSTREAM-UNDERFLOW (RUNES:XSTREAM))
     #<unavailable argument>
     #<unavailable argument>
     #<RUNES:XSTREAM [main document :MAIN NIL]>)
16: (CXML::READ-NAME-TOKEN #<unavailable argument>)
17: (CXML::READ-TAG-2
     #S(CXML::ZSTREAM
        :TOKEN-CATEGORY :SEEN-<
        :TOKEN-SEMANTIC NIL
        :INPUT-STACK (#<RUNES:XSTREAM [main document :MAIN NIL]>))
     #<RUNES:XSTREAM [main document :MAIN NIL]>
     :STAG)
18: (CXML::FIX-SEEN-<
     #S(CXML::ZSTREAM
        :TOKEN-CATEGORY :SEEN-<
        :TOKEN-SEMANTIC NIL
        :INPUT-STACK (#<RUNES:XSTREAM [main document :MAIN NIL]>)))
19: (CXML::P/DOCUMENT
     #S(CXML::ZSTREAM
        :TOKEN-CATEGORY :SEEN-<
        :TOKEN-SEMANTIC NIL
        :INPUT-STACK (#<RUNES:XSTREAM [main document :MAIN NIL]>))
     #<RUNE-DOM::DOM-BUILDER {B8EB0B9}>)[:EXTERNAL]
20: ((LAMBDA (CXML::ZSTREAM))
     #S(CXML::ZSTREAM
        :TOKEN-CATEGORY :SEEN-<
        :TOKEN-SEMANTIC NIL
        :INPUT-STACK (#<RUNES:XSTREAM [main document :MAIN NIL]>)))
21: (CXML::CALL-WITH-ZSTREAM
     #<CLOSURE (LAMBDA #) {B8EE055}>
     #S(CXML::ZSTREAM
        :TOKEN-CATEGORY :SEEN-<
        :TOKEN-SEMANTIC NIL
        :INPUT-STACK (#<RUNES:XSTREAM [main document :MAIN NIL]>)))
22: (CXML::PARSE-XSTREAM
     #<RUNES:XSTREAM [main document :MAIN NIL]>
     #<RUNE-DOM::DOM-BUILDER {B8EB0B9}>)[:EXTERNAL]
23: (ROUNDS-WEB::ANALYTICS-SERVICE) ;;; This is my service I've posted the
sources next
24: ((SB-PCL::FAST-METHOD HUNCHENTOOT:HANDLE-REQUEST
      (HUNCHENTOOT:ACCEPTOR HUNCHENTOOT:REQUEST))
     #<unavailable argument>
     #<unavailable argument>
     #<HUNCHENTOOT:ACCEPTOR (host *, port 8080)>
     #<HUNCHENTOOT:REQUEST {B8E8A11}>)
25: ((SB-PCL::FAST-METHOD HUNCHENTOOT:PROCESS-REQUEST (T))
     #<unavailable argument>
     #<unavailable argument>
     #<HUNCHENTOOT:REQUEST {B8E8A11}>)
26: ((SB-PCL::FAST-METHOD HUNCHENTOOT:PROCESS-CONNECTION
      (HUNCHENTOOT:ACCEPTOR T))
     #<unavailable argument>
     #<unavailable argument>
     #<HUNCHENTOOT:ACCEPTOR (host *, port 8080)>
     #<USOCKET:STREAM-USOCKET {B8E0B31}>)
27: ((SB-PCL::FAST-METHOD HUNCHENTOOT:PROCESS-CONNECTION :AROUND
      (HUNCHENTOOT:ACCEPTOR T))
     #<unavailable argument>
     #S(SB-PCL::FAST-METHOD-CALL
        :FUNCTION #<FUNCTION #>
        :PV NIL
        :NEXT-METHOD-CALL NIL
        :ARG-INFO (2))
     #<HUNCHENTOOT:ACCEPTOR (host *, port 8080)>
     #<USOCKET:STREAM-USOCKET {B8E0B31}>)
28: ((LAMBDA ()))
29: ((FLET #:WITHOUT-INTERRUPTS-BODY-[BLOCK353]358))
30: ((FLET SB-THREAD::WITH-MUTEX-THUNK))
31: ((FLET #:WITHOUT-INTERRUPTS-BODY-[CALL-WITH-MUTEX]267))
32: (SB-THREAD::CALL-WITH-MUTEX
     #<CLOSURE (FLET SB-THREAD::WITH-MUTEX-THUNK) {B6C77205}>
     #S(SB-THREAD:MUTEX
        :NAME "thread result lock"
        :%OWNER #<SB-THREAD:THREAD "Hunchentoot worker (client:
127.0.0.1:39378)" RUNNING {B8E2391}>
        :STATE 1)
     #<SB-THREAD:THREAD "Hunchentoot worker (client: 127.0.0.1:39378)"
RUNNING {B8E2391}>
     T)
33: ((LAMBDA ()))
34: ("foreign function: #x8066E3B")
35: ("foreign function: #x8052ABD")
36: ("foreign function: #x805DC00")
37: ("foreign function: #xB7FB696E")

[2011-07-06 14:20:27 [ERROR]] Error while processing connection:
#<SB-SYS:FD-STREAM for "a socket" {B8E0AA1}> is closed


And here's the code for that service:

(in-package :rounds-web)

(defun split-no-last (subject by)
  (loop with last = 0
     for i = (position by subject :start last)
     if i
     collect (subseq subject last i) into parts and
     do (setf last (1+ i))
     else
       when (> (1- (length subject)) last)
       collect (subseq subject last) into parts
       end and
     return parts
     end))

(defun time-value (raw-value)
  (let* ((pos (position #\. raw-value))
 (result (list (subseq raw-value 0 pos)))
 (raw-length (length raw-value)))
    (if (< pos raw-length)
(append result (list (subseq raw-value (1+ pos) raw-length)))
result)))

(defun parse-name (attribute)
  ;; *round*, *category* and *event-type* are hash tables defined elsewhere
  `(,(gethash (subseq attribute 0 1) *round*)
     ,(gethash (subseq attribute 1 3) *category*)
     ,(gethash (subseq attribute 3) *event-type*)))

(defun print-attribute (stream attribute val)
  (format stream "Event: Round ~a | Category ~a | Type ~a~&"
  (first attribute)
  (second attribute)
  (third attribute))
  (loop for v in val
     for split = (time-value v)
     for time = (first split)
     for value = (if (> (length split) 1) (second split) nil)
     do (format stream "    Time: ~a, Value: ~a~&" time value)))

(defun save-parsed-events (xml)
  (with-open-file (stream "./analytics.log"
  :direction :output
  :if-exists :supersede)
    (loop for node across (dom:child-nodes xml)
       do (when (eq (dom:node-type node) :element)
    (format stream "VideoSessionId: ~a
=========================================~&"
    (subseq (dom:node-name node) 1))
    (when (dom:attributes node)
      (loop with attributes = (dom:attributes node)
 for n from 0 upto (1- (dom:length attributes))
 for attribute = (dom:item attributes n)
 do (print-attribute
     stream (parse-name (dom:name attribute))
     (split-no-last
      (dom:get-attribute node (dom:name attribute)) #\,))))))))

(defun analytics-service ()
  (save-parsed-events
   (dom:first-child
    (cxml:parse-stream
     (hunchentoot:raw-post-data
      :request hunchentoot:*request*
      :want-stream t)
     (cxml-dom:make-dom-builder)))))

This code isn't meant for production, all it does it mocks a real service
which is meant to do the same thing so I could use it for testing, yet, I'd
of course like it to work :)
Please, if you have anything to suggest, I'd be very happy to hear!

Thanks!

Oleg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20110706/e495a587/attachment.html>

From hans.huebner at gmail.com  Wed Jul  6 13:23:30 2011
From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=)
Date: Wed, 6 Jul 2011 15:23:30 +0200
Subject: [hunchentoot-devel] Timing out when reading long post requests?
In-Reply-To: <CAJQBtgn_PG2vsg9NhT7sXV6Yc6pU7rUMwx5P0-8PjHt2etWN+w@mail.gmail.com>
References: <CAJQBtgn_PG2vsg9NhT7sXV6Yc6pU7rUMwx5P0-8PjHt2etWN+w@mail.gmail.com>
Message-ID: <CABj0bwKo8f=yUQpPnO_9DPJEh-yAmCrPw-WyTq7yWyK_zby7rA@mail.gmail.com>

Oleg,

from looking at your backtrace it appears as if the client does not
send data for longer than the socket timeout.  What client do you use
to send the data?  Can you try other clients (wget, curl) or browsers?
 Same behaviour?

-Hans

On Wed, Jul 6, 2011 at 1:41 PM, Oleg Sivokon <olegsivokon at gmail.com> wrote:
> Hello, I'm not sure what is causing this error (please see the stack trace
> below), all I can say it's relatively big XML being sent. I must be doing
> something tremendously inefficient or else this error means something else,
> but I hope you would be able to advise:
> [2011-07-06 14:20:27 [ERROR]] I/O timeout reading #<SB-SYS:FD-STREAM for "a
> socket" {B8E0AA1}>.
> 0: (SB-DEBUG::MAP-BACKTRACE #<CLOSURE (LAMBDA #) {B9034D5}>)[:EXTERNAL]
> 1: (BACKTRACE 536870911 #<SB-IMPL::STRING-OUTPUT-STREAM {B903471}>)
> 2: (TRIVIAL-BACKTRACE:PRINT-BACKTRACE-TO-STREAM
> ? ? #<SB-IMPL::STRING-OUTPUT-STREAM {B903471}>)
> 3: (HUNCHENTOOT::GET-BACKTRACE)
> 4: ((FLET #:LAMBDA284) #<SB-SYS:IO-TIMEOUT {B903139}>)
> 5: (SIGNAL #<SB-SYS:IO-TIMEOUT {B903139}>)[:EXTERNAL]
> 6: (ERROR SB-SYS:IO-TIMEOUT)[:EXTERNAL]
> 7: (SB-IMPL::SIGNAL-TIMEOUT SB-SYS:IO-TIMEOUT)[:EXTERNAL]
> 8: (SB-IMPL::REFILL-INPUT-BUFFER #<SB-SYS:FD-STREAM for "a socket"
> {B8E0AA1}>)
> 9: (SB-IMPL::FD-STREAM-READ-N-BYTES
> ? ? #<SB-SYS:FD-STREAM for "a socket" {B8E0AA1}>
> ? ? #(97 108 121 116 105 99 115 62 10 32 32 102 49 50 51 52 53 54 55 56 57
> 48
> . . . long array of data
> )
> ? ? 0
> ? ? 8191
> ? ? NIL)
> 10: (SB-IMPL::ANSI-STREAM-READ-SEQUENCE
> ? ? ?#(97 108 121 116 105 99 115 62 10 32 32 102 49 50 51 52 53 54 55 56 57
> 48
> . . . long array of data
> )
> ? ? ?#<SB-SYS:FD-STREAM for "a socket" {B8E0AA1}>
> ? ? ?0
> ? ? ?8191)
> 11: (READ-SEQUENCE
> ? ? ?#(97 108 121 116 105 99 115 62 10 32 32 102 49 50 51 52 53 54 55 56 57
> 48
> . . . long array of data
> )
> ? ? ?#<SB-SYS:FD-STREAM for "a socket" {B8E0AA1}>)[:EXTERNAL]
> 12: ((SB-PCL::FAST-METHOD TRIVIAL-GRAY-STREAMS:STREAM-READ-SEQUENCE
> ? ? ? (FLEXI-STREAMS:FLEXI-INPUT-STREAM T T T))
> ? ? ?#<unavailable argument>
> ? ? ?#<unavailable argument>
> ? ? ?#<unavailable argument>
> ? ? ?#<unavailable argument>
> ? ? ?#<unavailable argument>
> ? ? ?#<unavailable argument>)[:EXTERNAL]
> 13: ((LAMBDA
> ? ? ? ? ?(SB-PCL::.PV. SB-PCL::.NEXT-METHOD-CALL. SB-PCL::.ARG0.
> SB-PCL::.ARG1.
> ? ? ? ? ? SB-PCL::.ARG2. SB-PCL::.ARG3. SB-INT:&MORE
> ? ? ? ? ? SB-PCL::.DFUN-MORE-CONTEXT. SB-PCL::.DFUN-MORE-COUNT.))
> ? ? ?#<unused argument>
> ? ? ?#<unused argument>
> ? ? ?#<FLEXI-STREAMS:FLEXI-IO-STREAM {B8EA781}>
> ? ? ?#(97 108 121 116 105 99 115 62 10 32 32 102 49 50 51 52 53 54 55 56 57
> 48
> . . . long array of data
> )
> ? ? ?0
> ? ? ?8191
> ? ? ?-307111303
> ? ? ?0)
> 14: (READ-SEQUENCE
> ? ? ?#(97 108 121 116 105 99 115 62 10 32 32 102 49 50 51 52 53 54 55 56 57
> 48
> . . . long array of data
> )
> ? ? ?#<FLEXI-STREAMS:FLEXI-IO-STREAM {B8EA781}>)[:EXTERNAL]
> 15: ((SB-PCL::FAST-METHOD RUNES::XSTREAM-UNDERFLOW (RUNES:XSTREAM))
> ? ? ?#<unavailable argument>
> ? ? ?#<unavailable argument>
> ? ? ?#<RUNES:XSTREAM [main document :MAIN NIL]>)
> 16: (CXML::READ-NAME-TOKEN #<unavailable argument>)
> 17: (CXML::READ-TAG-2
> ? ? ?#S(CXML::ZSTREAM
> ? ? ? ? :TOKEN-CATEGORY :SEEN-<
> ? ? ? ? :TOKEN-SEMANTIC NIL
> ? ? ? ? :INPUT-STACK (#<RUNES:XSTREAM [main document :MAIN NIL]>))
> ? ? ?#<RUNES:XSTREAM [main document :MAIN NIL]>
> ? ? ?:STAG)
> 18: (CXML::FIX-SEEN-<
> ? ? ?#S(CXML::ZSTREAM
> ? ? ? ? :TOKEN-CATEGORY :SEEN-<
> ? ? ? ? :TOKEN-SEMANTIC NIL
> ? ? ? ? :INPUT-STACK (#<RUNES:XSTREAM [main document :MAIN NIL]>)))
> 19: (CXML::P/DOCUMENT
> ? ? ?#S(CXML::ZSTREAM
> ? ? ? ? :TOKEN-CATEGORY :SEEN-<
> ? ? ? ? :TOKEN-SEMANTIC NIL
> ? ? ? ? :INPUT-STACK (#<RUNES:XSTREAM [main document :MAIN NIL]>))
> ? ? ?#<RUNE-DOM::DOM-BUILDER {B8EB0B9}>)[:EXTERNAL]
> 20: ((LAMBDA (CXML::ZSTREAM))
> ? ? ?#S(CXML::ZSTREAM
> ? ? ? ? :TOKEN-CATEGORY :SEEN-<
> ? ? ? ? :TOKEN-SEMANTIC NIL
> ? ? ? ? :INPUT-STACK (#<RUNES:XSTREAM [main document :MAIN NIL]>)))
> 21: (CXML::CALL-WITH-ZSTREAM
> ? ? ?#<CLOSURE (LAMBDA #) {B8EE055}>
> ? ? ?#S(CXML::ZSTREAM
> ? ? ? ? :TOKEN-CATEGORY :SEEN-<
> ? ? ? ? :TOKEN-SEMANTIC NIL
> ? ? ? ? :INPUT-STACK (#<RUNES:XSTREAM [main document :MAIN NIL]>)))
> 22: (CXML::PARSE-XSTREAM
> ? ? ?#<RUNES:XSTREAM [main document :MAIN NIL]>
> ? ? ?#<RUNE-DOM::DOM-BUILDER {B8EB0B9}>)[:EXTERNAL]
> 23: (ROUNDS-WEB::ANALYTICS-SERVICE) ;;; This is my service I've posted the
> sources next
> 24: ((SB-PCL::FAST-METHOD HUNCHENTOOT:HANDLE-REQUEST
> ? ? ? (HUNCHENTOOT:ACCEPTOR HUNCHENTOOT:REQUEST))
> ? ? ?#<unavailable argument>
> ? ? ?#<unavailable argument>
> ? ? ?#<HUNCHENTOOT:ACCEPTOR (host *, port 8080)>
> ? ? ?#<HUNCHENTOOT:REQUEST {B8E8A11}>)
> 25: ((SB-PCL::FAST-METHOD HUNCHENTOOT:PROCESS-REQUEST (T))
> ? ? ?#<unavailable argument>
> ? ? ?#<unavailable argument>
> ? ? ?#<HUNCHENTOOT:REQUEST {B8E8A11}>)
> 26: ((SB-PCL::FAST-METHOD HUNCHENTOOT:PROCESS-CONNECTION
> ? ? ? (HUNCHENTOOT:ACCEPTOR T))
> ? ? ?#<unavailable argument>
> ? ? ?#<unavailable argument>
> ? ? ?#<HUNCHENTOOT:ACCEPTOR (host *, port 8080)>
> ? ? ?#<USOCKET:STREAM-USOCKET {B8E0B31}>)
> 27: ((SB-PCL::FAST-METHOD HUNCHENTOOT:PROCESS-CONNECTION :AROUND
> ? ? ? (HUNCHENTOOT:ACCEPTOR T))
> ? ? ?#<unavailable argument>
> ? ? ?#S(SB-PCL::FAST-METHOD-CALL
> ? ? ? ? :FUNCTION #<FUNCTION #>
> ? ? ? ? :PV NIL
> ? ? ? ? :NEXT-METHOD-CALL NIL
> ? ? ? ? :ARG-INFO (2))
> ? ? ?#<HUNCHENTOOT:ACCEPTOR (host *, port 8080)>
> ? ? ?#<USOCKET:STREAM-USOCKET {B8E0B31}>)
> 28: ((LAMBDA ()))
> 29: ((FLET #:WITHOUT-INTERRUPTS-BODY-[BLOCK353]358))
> 30: ((FLET SB-THREAD::WITH-MUTEX-THUNK))
> 31: ((FLET #:WITHOUT-INTERRUPTS-BODY-[CALL-WITH-MUTEX]267))
> 32: (SB-THREAD::CALL-WITH-MUTEX
> ? ? ?#<CLOSURE (FLET SB-THREAD::WITH-MUTEX-THUNK) {B6C77205}>
> ? ? ?#S(SB-THREAD:MUTEX
> ? ? ? ? :NAME "thread result lock"
> ? ? ? ? :%OWNER #<SB-THREAD:THREAD "Hunchentoot worker (client:
> 127.0.0.1:39378)" RUNNING {B8E2391}>
> ? ? ? ? :STATE 1)
> ? ? ?#<SB-THREAD:THREAD "Hunchentoot worker (client: 127.0.0.1:39378)"
> RUNNING {B8E2391}>
> ? ? ?T)
> 33: ((LAMBDA ()))
> 34: ("foreign function: #x8066E3B")
> 35: ("foreign function: #x8052ABD")
> 36: ("foreign function: #x805DC00")
> 37: ("foreign function: #xB7FB696E")
> [2011-07-06 14:20:27 [ERROR]] Error while processing connection:
> #<SB-SYS:FD-STREAM for "a socket" {B8E0AA1}> is closed
>
> And here's the code for that service:
> (in-package :rounds-web)
> (defun split-no-last (subject by)
> ? (loop with last = 0
> ? ? ?for i = (position by subject :start last)
> ? ? ?if i
> ? ? ?collect (subseq subject last i) into parts and
> ? ? ?do (setf last (1+ i))
> ? ? ?else
> ? ? ? ?when (> (1- (length subject)) last)
> ? ? ? ?collect (subseq subject last) into parts
> ? ? ? ?end and
> ? ? ?return parts
> ? ? ?end))
> (defun time-value (raw-value)
> ? (let* ((pos (position #\. raw-value))
> (result (list (subseq raw-value 0 pos)))
> (raw-length (length raw-value)))
> ? ? (if (< pos raw-length)
> (append result (list (subseq raw-value (1+ pos) raw-length)))
> result)))
> (defun parse-name (attribute)
> ? ;; *round*, *category* and *event-type* are hash tables defined elsewhere
> ? `(,(gethash (subseq attribute 0 1) *round*)
> ? ? ?,(gethash (subseq attribute 1 3) *category*)
> ? ? ?,(gethash (subseq attribute 3) *event-type*)))
> (defun print-attribute (stream attribute val)
> ? (format stream "Event: Round ~a | Category ~a | Type ~a~&"
> ?(first attribute)
> ?(second attribute)
> ?(third attribute))
> ? (loop for v in val
> ? ? ?for split = (time-value v)
> ? ? ?for time = (first split)
> ? ? ?for value = (if (> (length split) 1) (second split) nil)
> ? ? ?do (format stream " ? ?Time: ~a, Value: ~a~&" time value)))
> (defun save-parsed-events (xml)
> ? (with-open-file (stream "./analytics.log"
> ?:direction :output
> ?:if-exists :supersede)
> ? ? (loop for node across (dom:child-nodes xml)
> ? ? ? ?do (when (eq (dom:node-type node) :element)
> ? ?(format stream "VideoSessionId: ~a
> =========================================~&"
> ? ?(subseq (dom:node-name node) 1))
> ? ?(when (dom:attributes node)
> ? ? ?(loop with attributes = (dom:attributes node)
> for n from 0 upto (1- (dom:length attributes))
> for attribute = (dom:item attributes n)
> do (print-attribute
> ? ? stream (parse-name (dom:name attribute))
> ? ? (split-no-last
> ? ? ?(dom:get-attribute node (dom:name attribute)) #\,))))))))
> (defun analytics-service ()
> ? (save-parsed-events
> ? ?(dom:first-child
> ? ? (cxml:parse-stream
> ? ? ?(hunchentoot:raw-post-data
> ? ? ? :request hunchentoot:*request*
> ? ? ? :want-stream t)
> ? ? ?(cxml-dom:make-dom-builder)))))
> This code isn't meant for production, all it does it mocks a real service
> which is meant to do the same thing so I could use it for testing, yet, I'd
> of course like it to work :)
> Please, if you have anything to suggest, I'd be very happy to hear!
> Thanks!
> Oleg
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
>



From olegsivokon at gmail.com  Wed Jul  6 15:10:30 2011
From: olegsivokon at gmail.com (Oleg Sivokon)
Date: Wed, 6 Jul 2011 18:10:30 +0300
Subject: [hunchentoot-devel] Timing out when reading long post requests?
In-Reply-To: <CABj0bwKo8f=yUQpPnO_9DPJEh-yAmCrPw-WyTq7yWyK_zby7rA@mail.gmail.com>
References: <CAJQBtgn_PG2vsg9NhT7sXV6Yc6pU7rUMwx5P0-8PjHt2etWN+w@mail.gmail.com>
	<CABj0bwKo8f=yUQpPnO_9DPJEh-yAmCrPw-WyTq7yWyK_zby7rA@mail.gmail.com>
Message-ID: <CAJQBtg=VuSBRwi1_eEgREPbkNoJ4=idLLcdp7nF3d_ke7_S5mw@mail.gmail.com>

Hi Hans, thanks for reply. The client is Flash, I'm pretty confident about
the content (I could trace it with tcpdump, so that's not the issue). I've
also tried (cxml:parse-octets (hunchentoot:raw-post-data :request
hunchentoot:*request* :force-binary t), and it worked just as I would expect
it. So it's either CXML is doing something strange with the stream, or I'm
supposed to do something with the stream before (or after) giving it to
CXML, or there's a chance something isn't right with stream produced by
Hunchentoot.
So, would you have an idea of how would I verify that? It's not really a
life and death issue, since I believe I could survive with string instead of
stream, but just to educate myself, I'd like to know :)

Thanks.

Oleg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20110706/6eca4ce7/attachment.html>

From austin at pettomato.com  Wed Jul  6 16:47:32 2011
From: austin at pettomato.com (Austin Haas)
Date: Wed, 6 Jul 2011 09:47:32 -0700
Subject: [hunchentoot-devel] Timing out when reading long post requests?
In-Reply-To: <CAJQBtg=VuSBRwi1_eEgREPbkNoJ4=idLLcdp7nF3d_ke7_S5mw@mail.gmail.com>
References: <CAJQBtgn_PG2vsg9NhT7sXV6Yc6pU7rUMwx5P0-8PjHt2etWN+w@mail.gmail.com>
	<CABj0bwKo8f=yUQpPnO_9DPJEh-yAmCrPw-WyTq7yWyK_zby7rA@mail.gmail.com>
	<CAJQBtg=VuSBRwi1_eEgREPbkNoJ4=idLLcdp7nF3d_ke7_S5mw@mail.gmail.com>
Message-ID: <20110706164732.GA6603@mars.chicago>


Can you test without Hunchentoot, like this?

(with-input-from-string (s your-string)
  (cxml:parse-stream 
   s
  (cxml-dom:make-dom-builder))

You could also capture whatever hunchentoot is returning via
raw-post-data in a special variable to compare it with your expected
data. It should be easy to determine if the issue falls within
Hunchentoot or cxml.

It's been a while since I've done any network stuff with Flash, but I
remember that it terminates messages with a null byte. Make sure you
aren't missing that when you test.

-austin

-- 
Austin Haas
Pet Tomato, Inc.
http://pettomato.com

On Wed Jul 06 18:10 , Oleg Sivokon wrote:
> Hi Hans, thanks for reply. The client is Flash, I'm pretty confident about
> the content (I could trace it with tcpdump, so that's not the issue). I've
> also tried (cxml:parse-octets (hunchentoot:raw-post-data :request
> hunchentoot:*request* :force-binary t), and it worked just as I would expect
> it. So it's either CXML is doing something strange with the stream, or I'm
> supposed to do something with the stream before (or after) giving it to
> CXML, or there's a chance something isn't right with stream produced by
> Hunchentoot.
> So, would you have an idea of how would I verify that? It's not really a
> life and death issue, since I believe I could survive with string instead of
> stream, but just to educate myself, I'd like to know :)
> 
> Thanks.
> 
> Oleg

> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel




From olegsivokon at gmail.com  Thu Jul  7 07:20:06 2011
From: olegsivokon at gmail.com (Oleg Sivokon)
Date: Thu, 7 Jul 2011 10:20:06 +0300
Subject: [hunchentoot-devel] Timing out when reading long post requests?
In-Reply-To: <20110706164732.GA6603@mars.chicago>
References: <CAJQBtgn_PG2vsg9NhT7sXV6Yc6pU7rUMwx5P0-8PjHt2etWN+w@mail.gmail.com>
	<CABj0bwKo8f=yUQpPnO_9DPJEh-yAmCrPw-WyTq7yWyK_zby7rA@mail.gmail.com>
	<CAJQBtg=VuSBRwi1_eEgREPbkNoJ4=idLLcdp7nF3d_ke7_S5mw@mail.gmail.com>
	<20110706164732.GA6603@mars.chicago>
Message-ID: <CAJQBtgna3eWjDRZ5iXHori=g2dLK=jdE6dMNP35QVUXg9qOdzA@mail.gmail.com>

Hi Austin. I did try parsing the same XML outside the acceptor function, but
using the same code, and it worked. It also worked if I did like you
suggested:

(defun analytics-service ()
  (save-parsed-events
   (dom:first-child
    (with-input-from-string
(stream (hunchentoot:raw-post-data
 :request hunchentoot:*request*
 :force-text t))
      (cxml:parse-stream stream)
      (cxml-dom:make-dom-builder))))
  "ok")

i.e. if I change the acceptor to look like this - no error and the data is
parsed and logged, streams closed etc. It only happens in my original code.
I also read in docs that

If, however, you provide a true value for want-stream, the other parameters
are ignored and you'll get the content (flexi) stream to read from it
yourself. It is then your responsibility to read the correct amount of data,
because otherwise you won't be able to return a response to the client. The
stream will have its octet position set to 0. If the client provided a
Content-Length header, the stream will also have a corresponding bound, so
no matter whether the client used chunked encoding or not, you can always
read until EOF.

I've verified that content-length is correct, there isn't a null byte (Flash
sends null byte if you are using XMLSocket class, but this is an HTTP
request made by URLLoader). So it looks like something wrong with the stream
generated by Hunchentoot, or, probably CXML doesn't like that particular
kind of streams?

Best.

Oleg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20110707/a370d5e6/attachment.html>

From hans.huebner at gmail.com  Thu Jul  7 07:29:43 2011
From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=)
Date: Thu, 7 Jul 2011 09:29:43 +0200
Subject: [hunchentoot-devel] Timing out when reading long post requests?
In-Reply-To: <CAJQBtgna3eWjDRZ5iXHori=g2dLK=jdE6dMNP35QVUXg9qOdzA@mail.gmail.com>
References: <CAJQBtgn_PG2vsg9NhT7sXV6Yc6pU7rUMwx5P0-8PjHt2etWN+w@mail.gmail.com>
	<CABj0bwKo8f=yUQpPnO_9DPJEh-yAmCrPw-WyTq7yWyK_zby7rA@mail.gmail.com>
	<CAJQBtg=VuSBRwi1_eEgREPbkNoJ4=idLLcdp7nF3d_ke7_S5mw@mail.gmail.com>
	<20110706164732.GA6603@mars.chicago>
	<CAJQBtgna3eWjDRZ5iXHori=g2dLK=jdE6dMNP35QVUXg9qOdzA@mail.gmail.com>
Message-ID: <CABj0bwLhVO2wmv_Ukab2BeojRQxnqKkbMuU2Y-2QntDeNRKmKw@mail.gmail.com>

On Thu, Jul 7, 2011 at 9:20 AM, Oleg Sivokon <olegsivokon at gmail.com> wrote:
> I've verified that content-length is correct, there isn't a null byte (Flash
> sends null byte if you are using XMLSocket class, but this is an HTTP
> request made by URLLoader). So it looks like something wrong with the stream
> generated by Hunchentoot, or, probably CXML doesn't like that particular
> kind of streams?

Both are possibilities, but you'll have to do some more research to
pinpoint the original problem, if you are interested.  I'd first
verify that flexi-streams correctly interact with your grey-streams
implementation, considering a problem in that area to be more likely
than one in CXML.

If you have specific or theories, don't hesitate to ask!

-Hans



From vseloved at gmail.com  Thu Jul  7 07:31:22 2011
From: vseloved at gmail.com (Vsevolod Dyomkin)
Date: Thu, 7 Jul 2011 10:31:22 +0300
Subject: [hunchentoot-devel] Timing out when reading long post requests?
In-Reply-To: <CAJQBtgna3eWjDRZ5iXHori=g2dLK=jdE6dMNP35QVUXg9qOdzA@mail.gmail.com>
References: <CAJQBtgn_PG2vsg9NhT7sXV6Yc6pU7rUMwx5P0-8PjHt2etWN+w@mail.gmail.com>
	<CABj0bwKo8f=yUQpPnO_9DPJEh-yAmCrPw-WyTq7yWyK_zby7rA@mail.gmail.com>
	<CAJQBtg=VuSBRwi1_eEgREPbkNoJ4=idLLcdp7nF3d_ke7_S5mw@mail.gmail.com>
	<20110706164732.GA6603@mars.chicago>
	<CAJQBtgna3eWjDRZ5iXHori=g2dLK=jdE6dMNP35QVUXg9qOdzA@mail.gmail.com>
Message-ID: <CABhNRBZn=P-wUbUCcxQuVnwTjJz7u1U_GE4r+7Dr1HcrH4e5JQ@mail.gmail.com>

One thing, that I stumbled upon working with Drakma, is the treatment of EOL
in Chunga.
Maybe, (setf chunga:*accept-bogus-eols* t) might help.

Best,
Vsevolod


On Thu, Jul 7, 2011 at 10:20 AM, Oleg Sivokon <olegsivokon at gmail.com> wrote:

> Hi Austin. I did try parsing the same XML outside the acceptor function,
> but using the same code, and it worked. It also worked if I did like you
> suggested:
>
> (defun analytics-service ()
>   (save-parsed-events
>    (dom:first-child
>     (with-input-from-string
> (stream (hunchentoot:raw-post-data
>  :request hunchentoot:*request*
>  :force-text t))
>       (cxml:parse-stream stream)
>       (cxml-dom:make-dom-builder))))
>   "ok")
>
> i.e. if I change the acceptor to look like this - no error and the data is
> parsed and logged, streams closed etc. It only happens in my original code.
> I also read in docs that
>
> If, however, you provide a true value for want-stream, the other parameters
> are ignored and you'll get the content (flexi) stream to read from it
> yourself. It is then your responsibility to read the correct amount of data,
> because otherwise you won't be able to return a response to the client. The
> stream will have its octet position set to 0. If the client provided a
> Content-Length header, the stream will also have a corresponding bound, so
> no matter whether the client used chunked encoding or not, you can always
> read until EOF.
>
> I've verified that content-length is correct, there isn't a null byte
> (Flash sends null byte if you are using XMLSocket class, but this is an HTTP
> request made by URLLoader). So it looks like something wrong with the stream
> generated by Hunchentoot, or, probably CXML doesn't like that particular
> kind of streams?
>
> Best.
>
> Oleg
>
> _______________________________________________
> 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: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20110707/26f39ee0/attachment.html>

From olegsivokon at gmail.com  Thu Jul  7 07:32:17 2011
From: olegsivokon at gmail.com (Oleg Sivokon)
Date: Thu, 7 Jul 2011 10:32:17 +0300
Subject: [hunchentoot-devel] Timing out when reading long post requests?
In-Reply-To: <CAJQBtgna3eWjDRZ5iXHori=g2dLK=jdE6dMNP35QVUXg9qOdzA@mail.gmail.com>
References: <CAJQBtgn_PG2vsg9NhT7sXV6Yc6pU7rUMwx5P0-8PjHt2etWN+w@mail.gmail.com>
	<CABj0bwKo8f=yUQpPnO_9DPJEh-yAmCrPw-WyTq7yWyK_zby7rA@mail.gmail.com>
	<CAJQBtg=VuSBRwi1_eEgREPbkNoJ4=idLLcdp7nF3d_ke7_S5mw@mail.gmail.com>
	<20110706164732.GA6603@mars.chicago>
	<CAJQBtgna3eWjDRZ5iXHori=g2dLK=jdE6dMNP35QVUXg9qOdzA@mail.gmail.com>
Message-ID: <CAJQBtgn20Q1NedJR4B026rkwT9a3rGrE16LDErtu9-W6hULQCg@mail.gmail.com>

Oh, sorry for double posting... Actually these the connection dumps:

Request:

POST /analytics HTTP/1.1
Host: localhost:8080
Accept: */*
Accept-Language: en-us
User-Agent: Shockwave Flash
x-flash-version: 10,0,45,2
Content-Type: application/x-www-form-urlencoded
Content-Length: 1819
Expect: 100-continue

HTTP/1.1 100 Continue
<xml data goes here>

HTTP/1.1 500 Internal Server Error
Content-Length: 297
Date: Thu, 07 Jul 2011 07:26:04 GMT
Server: Hunchentoot 1.1.1
Content-Type: text/html; charset=iso-8859-1

I didn't notice at first that Flash was sending continue headers, thought it
was all in one bulk... hm... OK, I'll have to check that then

Best.

Oleg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20110707/dc5294cd/attachment.html>

From olegsivokon at gmail.com  Thu Jul  7 08:01:21 2011
From: olegsivokon at gmail.com (Oleg Sivokon)
Date: Thu, 7 Jul 2011 11:01:21 +0300
Subject: [hunchentoot-devel] Timing out when reading long post requests?
In-Reply-To: <CABhNRBZn=P-wUbUCcxQuVnwTjJz7u1U_GE4r+7Dr1HcrH4e5JQ@mail.gmail.com>
References: <CAJQBtgn_PG2vsg9NhT7sXV6Yc6pU7rUMwx5P0-8PjHt2etWN+w@mail.gmail.com>
	<CABj0bwKo8f=yUQpPnO_9DPJEh-yAmCrPw-WyTq7yWyK_zby7rA@mail.gmail.com>
	<CAJQBtg=VuSBRwi1_eEgREPbkNoJ4=idLLcdp7nF3d_ke7_S5mw@mail.gmail.com>
	<20110706164732.GA6603@mars.chicago>
	<CAJQBtgna3eWjDRZ5iXHori=g2dLK=jdE6dMNP35QVUXg9qOdzA@mail.gmail.com>
	<CABhNRBZn=P-wUbUCcxQuVnwTjJz7u1U_GE4r+7Dr1HcrH4e5JQ@mail.gmail.com>
Message-ID: <CAJQBtgkoSCE1x9cP8XvA+ixrPAdozx1StV4NuWPRj5KwtBujew@mail.gmail.com>

Sorry for yet another double post. My previous one was wrong:
with-input-from-string
makes sting stream and CXML wants unsigned-byte 8, so it failed early,
before even parsing, which I took to be a successful result :S
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20110707/0c0abf08/attachment.html>

From olegsivokon at gmail.com  Thu Jul  7 08:31:06 2011
From: olegsivokon at gmail.com (Oleg Sivokon)
Date: Thu, 7 Jul 2011 11:31:06 +0300
Subject: [hunchentoot-devel] Timing out when reading long post requests?
In-Reply-To: <CAJQBtgkoSCE1x9cP8XvA+ixrPAdozx1StV4NuWPRj5KwtBujew@mail.gmail.com>
References: <CAJQBtgn_PG2vsg9NhT7sXV6Yc6pU7rUMwx5P0-8PjHt2etWN+w@mail.gmail.com>
	<CABj0bwKo8f=yUQpPnO_9DPJEh-yAmCrPw-WyTq7yWyK_zby7rA@mail.gmail.com>
	<CAJQBtg=VuSBRwi1_eEgREPbkNoJ4=idLLcdp7nF3d_ke7_S5mw@mail.gmail.com>
	<20110706164732.GA6603@mars.chicago>
	<CAJQBtgna3eWjDRZ5iXHori=g2dLK=jdE6dMNP35QVUXg9qOdzA@mail.gmail.com>
	<CABhNRBZn=P-wUbUCcxQuVnwTjJz7u1U_GE4r+7Dr1HcrH4e5JQ@mail.gmail.com>
	<CAJQBtgkoSCE1x9cP8XvA+ixrPAdozx1StV4NuWPRj5KwtBujew@mail.gmail.com>
Message-ID: <CAJQBtgmy-AoB7eOy49iE1=tVduD1Km_nv9xu7E6hMR4DVwjz=A@mail.gmail.com>

OK, this is the last one for today at least :) Here's how it worked, too,
now 100% sure, tried it a few times with refreshing all loggs etc. So it
looks like there might be some particular problem with maybe appending bytes
from the post body as it is received or something similar? Well, just a
guess...

POST /analytics HTTP/1.1
Host: localhost:8080
Accept: */*
Accept-Language: en-us
User-Agent: Shockwave Flash
x-flash-version: 10,0,45,2
Content-Type: application/x-www-form-urlencoded
Content-Length: 1821
Expect: 100-continue

HTTP/1.1 100 Continue
<xml data>
-------------------------------------------------------------------
HTTP/1.1 200 OK
Content-Length: 2
Date: Thu, 07 Jul 2011 08:20:50 GMT
Server: Hunchentoot 1.1.1
Content-Type: text/html; charset=iso-8859-1

ok

This worked:

(defun analytics-service ()
  (save-parsed-events
   (dom:first-child
    (flexi-streams:with-input-from-sequence
(stream (hunchentoot:raw-post-data
 :request hunchentoot:*request*
 :force-binary t))
      (cxml:parse-stream
       stream (cxml-dom:make-dom-builder)))))
  "ok")

Best.

Oleg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20110707/6da0b78c/attachment.html>

From member at linkedin.com  Wed Jul 13 21:38:56 2011
From: member at linkedin.com (=?UTF-8?Q?Eli_Naeher_=C3=BCber_LinkedIn?=)
Date: Wed, 13 Jul 2011 21:38:56 +0000 (UTC)
Subject: [hunchentoot-devel] Treten Sie meinem Netzwerk auf LinkedIn bei
Message-ID: <1628144834.16702834.1310593136387.JavaMail.app@ela4-bed39.prod>

LinkedIn
------------




    Eli Naeher m?chte Sie als Kontakt auf LinkedIn hinzuf?gen:
  
------------------------------------------

Ich m?chte Sie gerne zu meinem beruflichen Netzwerk auf LinkedIn hinzuf?gen.

Einladung von Eli Naeher annehmen
http://www.linkedin.com/e/bxhy9y-gq2tbc3i-6/53mvQnCmNTJiD3hCE0Ep5J1I-StDsAzUeZOQUI51/blk/I62814898_75/pmpxnSRJrSdvj4R5fnhv9ClRsDgZp6lQs6lzoQ5AomZIpn8_djtve3AUd34Uczp9bQF4gA9QozppbPwUcj8McP0PdjcLrCBxbOYWrSlI/EML_comm_afe/

Einladung von Eli Naeher anzeigen
http://www.linkedin.com/e/bxhy9y-gq2tbc3i-6/53mvQnCmNTJiD3hCE0Ep5J1I-StDsAzUeZOQUI51/blk/I62814898_75/0RdRYUejwQcjwOdAALqnpPbOYWrSlI/svi/ 
------------------------------------------

Wussten Sie schon, dass Sie sich mit Ihrem Fachwissen auf LinkedIn profilieren k?nnen, um Stellen- bzw. Beratungsangebote zu erhalten und Ihr berufliches Ansehen zu verbessern? Beantworten Sie Fragen unter "LinkedIn Fragen & Anworten", um in der weltweiten Gemeinschaft von Fach- und F?hrungskr?ften auf sich aufmerksam zu machen.
http://www.linkedin.com/e/bxhy9y-gq2tbc3i-6/abq/inv-24/

 
-- 
(c) 2011, LinkedIn Corporation
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20110713/138addb9/attachment.html>

From info at jensteich.de  Sat Jul 16 15:54:40 2011
From: info at jensteich.de (Jens Teich)
Date: Sat, 16 Jul 2011 17:54:40 +0200
Subject: [hunchentoot-devel] session-value
Message-ID: <4E21B440.5010905@jensteich.de>

Trying to update a project from 0.15.6 to 1.1.1.

(setf (session-value 'x) 42) throws error 'called session with unpaired 
keyword'.

What am I missing?

Jens



From hans.huebner at gmail.com  Sat Jul 16 16:37:00 2011
From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=)
Date: Sat, 16 Jul 2011 18:37:00 +0200
Subject: [hunchentoot-devel] session-value
In-Reply-To: <4E21B440.5010905@jensteich.de>
References: <4E21B440.5010905@jensteich.de>
Message-ID: <CABj0bwJ27_vwsVOfs+vCgKRmm8JnH_RBSf9ME6cviG=+qfR4rg@mail.gmail.com>

Hi Jens,

does hunchentoot-test work for you?  Did you look at the source of
hunchentoot-test to see whether it uses session-value the same way?

-Hans

On Sat, Jul 16, 2011 at 5:54 PM, Jens Teich <info at jensteich.de> wrote:
> Trying to update a project from 0.15.6 to 1.1.1.
>
> (setf (session-value 'x) 42) throws error 'called session with unpaired
> keyword'.
>
> What am I missing?
>
> Jens
>
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
>



From info at jensteich.de  Sat Jul 16 16:43:25 2011
From: info at jensteich.de (Jens Teich)
Date: Sat, 16 Jul 2011 18:43:25 +0200
Subject: [hunchentoot-devel] session-value
In-Reply-To: <CABj0bwJ27_vwsVOfs+vCgKRmm8JnH_RBSf9ME6cviG=+qfR4rg@mail.gmail.com>
References: <4E21B440.5010905@jensteich.de>
	<CABj0bwJ27_vwsVOfs+vCgKRmm8JnH_RBSf9ME6cviG=+qfR4rg@mail.gmail.com>
Message-ID: <4E21BFAD.9070007@jensteich.de>

Yes hunchentoot-test does work, but if I try

(hunchentoot:define-easy-handler (say-yo :uri "/yo") (name)
   (setf (hunchentoot:content-type*) "text/plain")
   (setf (session-value 'test) 42)
   (format nil "Hey~@[ ~A~]!" name))

I see the error.

Jens

Am 16.07.11 18:37, schrieb Hans H?bner:
> Hi Jens,
>
> does hunchentoot-test work for you?  Did you look at the source of
> hunchentoot-test to see whether it uses session-value the same way?
>
> -Hans
>
> On Sat, Jul 16, 2011 at 5:54 PM, Jens Teich<info at jensteich.de>  wrote:
>> Trying to update a project from 0.15.6 to 1.1.1.
>>
>> (setf (session-value 'x) 42) throws error 'called session with unpaired
>> keyword'.
>>
>> What am I missing?
>>
>> Jens




From hans.huebner at gmail.com  Sat Jul 16 17:05:00 2011
From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=)
Date: Sat, 16 Jul 2011 19:05:00 +0200
Subject: [hunchentoot-devel] session-value
In-Reply-To: <4E21BFAD.9070007@jensteich.de>
References: <4E21B440.5010905@jensteich.de>
	<CABj0bwJ27_vwsVOfs+vCgKRmm8JnH_RBSf9ME6cviG=+qfR4rg@mail.gmail.com>
	<4E21BFAD.9070007@jensteich.de>
Message-ID: <CABj0bwKSxqMcdH7aR_yqB4FuDzoFnubr=jfFoAeP14-+oVaGNw@mail.gmail.com>

On Sat, Jul 16, 2011 at 6:43 PM, Jens Teich <info at jensteich.de> wrote:
> Yes hunchentoot-test does work, but if I try
>
> (hunchentoot:define-easy-handler (say-yo :uri "/yo") (name)
> ?(setf (hunchentoot:content-type*) "text/plain")
> ?(setf (session-value 'test) 42)
> ?(format nil "Hey~@[ ~A~]!" name))
>
> I see the error.

Works for me.  You need to debug more.  Do you use quicklisp?

-Hans



From info at jensteich.de  Sat Jul 16 17:15:54 2011
From: info at jensteich.de (Jens Teich)
Date: Sat, 16 Jul 2011 19:15:54 +0200
Subject: [hunchentoot-devel] session-value
In-Reply-To: <CABj0bwKSxqMcdH7aR_yqB4FuDzoFnubr=jfFoAeP14-+oVaGNw@mail.gmail.com>
References: <4E21B440.5010905@jensteich.de>
	<CABj0bwJ27_vwsVOfs+vCgKRmm8JnH_RBSf9ME6cviG=+qfR4rg@mail.gmail.com>
	<4E21BFAD.9070007@jensteich.de>
	<CABj0bwKSxqMcdH7aR_yqB4FuDzoFnubr=jfFoAeP14-+oVaGNw@mail.gmail.com>
Message-ID: <4E21C74A.6050009@jensteich.de>

Am 16.07.11 19:05, schrieb Hans H?bner:
> On Sat, Jul 16, 2011 at 6:43 PM, Jens Teich<info at jensteich.de>  wrote:
>> Yes hunchentoot-test does work, but if I try
>>
>> (hunchentoot:define-easy-handler (say-yo :uri "/yo") (name)
>>   (setf (hunchentoot:content-type*) "text/plain")
>>   (setf (session-value 'test) 42)
>>   (format nil "Hey~@[ ~A~]!" name))
>>
>> I see the error.
>
Sorry stupid mistake.

Missing hunchentoot:sess...

Thanks
Jens





From simply.nitaai at gmail.com  Fri Jul 29 07:42:18 2011
From: simply.nitaai at gmail.com (Matus Kmit)
Date: Fri, 29 Jul 2011 09:42:18 +0200
Subject: [hunchentoot-devel] Get client's time
Message-ID: <CALvESw5XwY6uBbJNXqoLdA7EL+=yWx25mc2BrZjnctMCgv8ZTg@mail.gmail.com>

Hi everyone

i am new to web programming and hunchentoot. i have the following question:

How do one get client's time with hunchentoot? Does the http request
contain this information and can one inspect on that within
hunchentoot? Or what is the other way to do it?

On my main page, i need to know the exact hour and minute of the
client before generating the appropriate site content.

Thanks
Matus



From hans.huebner at gmail.com  Fri Jul 29 08:24:46 2011
From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=)
Date: Fri, 29 Jul 2011 10:24:46 +0200
Subject: [hunchentoot-devel] Get client's time
In-Reply-To: <CALvESw5XwY6uBbJNXqoLdA7EL+=yWx25mc2BrZjnctMCgv8ZTg@mail.gmail.com>
References: <CALvESw5XwY6uBbJNXqoLdA7EL+=yWx25mc2BrZjnctMCgv8ZTg@mail.gmail.com>
Message-ID: <CABj0bwJP_N6RNDke0C14qYyoFMir1SJ-8TWGrE4=ZChJNmVm7A@mail.gmail.com>

Matus,

times on the client and the server in a HTTP connection are not
synchronized, so you could not rely on the time sent by the client anyway.

The server can send its own timestamp when a resource was last modified in
the Last-Modified header, and that timestamp can be used by the client in
subsequent requests to prevent the server from generating and sending the
same content again if it has not been modified (Last-Modified-Since request
header).

Please refer to http://tools.ietf.org/html/rfc2616 for a precise description
of these headers and mechanisms.

HTH,
-Hans

On Fri, Jul 29, 2011 at 9:42 AM, Matus Kmit <simply.nitaai at gmail.com> wrote:

> Hi everyone
>
> i am new to web programming and hunchentoot. i have the following question:
>
> How do one get client's time with hunchentoot? Does the http request
> contain this information and can one inspect on that within
> hunchentoot? Or what is the other way to do it?
>
> On my main page, i need to know the exact hour and minute of the
> client before generating the appropriate site content.
>
> Thanks
> Matus
>
> _______________________________________________
> 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: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20110729/dba9d69a/attachment.html>

From simply.nitaai at gmail.com  Fri Jul 29 08:40:23 2011
From: simply.nitaai at gmail.com (Matus Kmit)
Date: Fri, 29 Jul 2011 10:40:23 +0200
Subject: [hunchentoot-devel] Get client's time
In-Reply-To: <CABj0bwJP_N6RNDke0C14qYyoFMir1SJ-8TWGrE4=ZChJNmVm7A@mail.gmail.com>
References: <CALvESw5XwY6uBbJNXqoLdA7EL+=yWx25mc2BrZjnctMCgv8ZTg@mail.gmail.com>
	<CABj0bwJP_N6RNDke0C14qYyoFMir1SJ-8TWGrE4=ZChJNmVm7A@mail.gmail.com>
Message-ID: <CALvESw7swx=2ROimnKEZeEsO7N-hxpaXoUeqyh=nrDVN=De6Bw@mail.gmail.com>

Hi Hans,

Thanks for the information, will investigate further on that...

Greetings,
Matus

On Fri, Jul 29, 2011 at 10:24 AM, Hans H?bner <hans.huebner at gmail.com> wrote:
> Matus,
> times on the client and the server in a HTTP connection are not
> synchronized, so you could not rely on the time sent by the client anyway.
> The server can send its own timestamp when a resource was last modified in
> the Last-Modified header, and that timestamp can be used by the client in
> subsequent requests to prevent the server from generating and sending the
> same content again if it has not been modified (Last-Modified-Since request
> header).
> Please refer to?http://tools.ietf.org/html/rfc2616?for a precise description
> of these headers and mechanisms.
> HTH,
> -Hans
>
> On Fri, Jul 29, 2011 at 9:42 AM, Matus Kmit <simply.nitaai at gmail.com> wrote:
>>
>> Hi everyone
>>
>> i am new to web programming and hunchentoot. i have the following
>> question:
>>
>> How do one get client's time with hunchentoot? Does the http request
>> contain this information and can one inspect on that within
>> hunchentoot? Or what is the other way to do it?
>>
>> On my main page, i need to know the exact hour and minute of the
>> client before generating the appropriate site content.
>>
>> Thanks
>> Matus
>>
>> _______________________________________________
>> 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
>