Re: lifetime of r-user in 2.0 tree
Aryeh Katz wrote: patch to remove erroneous comment supplied --- protocol.c Thu Sep 4 10:03:11 2003 +++ protocol-2.0.47.c Thu Sep 4 10:02:59 2003 @@ -1142,6 +1142,10 @@ } t = ap_pbase64decode(r-pool, auth_line); +/* Note that this allocation has to be made from r-connection-pool + * because it has the lifetime of the connection. The other allocations + * are temporary and can be tossed away any time. + */ r-user = ap_getword_nulls (r-pool, t, ':'); r-ap_auth_type = Basic; committed, thanks!
lifetime of r-user in 2.0 tree
There is a comment in protocol.c which states that the lifetime of r-user is per connection. Yet, the code only allocates from the request pool. Tracing this back, I see that in the 1.3 tree, the allocation is in fact from the connection. Can someone explain why the user information's lifespan was changed to per connection to per request? (not to mention updating the misleading comment in the 2.0 tree). Aryeh --- Aryeh Katz Secured-Services Inc.
Re: lifetime of r-user in 2.0 tree
Aryeh Katz wrote: There is a comment in protocol.c which states that the lifetime of r-user is per connection. Yet, the code only allocates from the request pool. Tracing this back, I see that in the 1.3 tree, the allocation is in fact from the connection. Can someone explain why the user information's lifespan was changed to per connection to per request? (not to mention updating the misleading comment in the 2.0 tree). The request is independent from the connection. I'd count the storage of the request user in r-connection in 1.3 as wrongly designed. The second is a technical reason. In 2.x connection and request are *really* separated, so storing the user in the connection structure would be even more problematic. nd
Re: lifetime of r-user in 2.0 tree
From: André Malo [EMAIL PROTECTED] The request is independent from the connection. I'd count the storage of the request user in r-connection in 1.3 as wrongly designed. The second is a technical reason. In 2.x connection and request are *really* separated, so storing the user in the connection structure would be even more problematic. patch to remove erroneous comment supplied --- protocol.c Thu Sep 4 10:03:11 2003 +++ protocol-2.0.47.c Thu Sep 4 10:02:59 2003 @@ -1142,6 +1142,10 @@ } t = ap_pbase64decode(r-pool, auth_line); +/* Note that this allocation has to be made from r-connection-pool + * because it has the lifetime of the connection. The other allocations + * are temporary and can be tossed away any time. + */ r-user = ap_getword_nulls (r-pool, t, ':'); r-ap_auth_type = Basic; nd --- Aryeh Katz Secured-Services Inc.
