Re: [Webware-discuss] rawInput does not work?

[Aaron H. <aaron@MetroNY.com>]

_SID_ on the query string is a very important feature if you need to 
serve client w/o cookies. I also don't use it, but as an appserver 
Webware should support 'cookie-less' sessions.

-Aaron Held

Jeff Johnson wrote:

>I pass the _SID_ on the query string for one of my sites that doesn't have an 
>SSL cert for its domain.  Since I have an SSL cert for another generic 
>payment domain on the same server, I just send the user to the secure domain 
>with the _SID_, it then calls the same instance of webkit that was running on 
>the unsecure domain.  If there is a different way of doing this, I'll switch, 
>I just wanted you all to know that the current feature is being used.
>
>-Jeff
>
>On Wednesday 30 April 2003 10:38 am, Geoffrey Talvola wrote:
>  
>
>>Terrel Shumway [mailto:tsh...@jd...] wrote:
>>    
>>
>>>4) made the session id logic reference cookies("_SID_") instead of
>>>value("_SID_") (and some related changes). Instead of putting
>>>the _SID_ into a
>>>Field, I added it directly as HTTPRequest._session_id (with a
>>>corresponding
>>>._sid_source=[None|"path"|"cookie"]).
>>>
>>>This will break the feature that allows you to pass the _SID_ in the
>>>query_string, but ../_SID_=..../ path rewriting is a better
>>>solution anyway
>>>(IMO). Maybe the session/path code could also look directly
>>>in the query string
>>>without triggering the POST reading code (if this feature is
>>>important enough to
>>>preserve).
>>>      
>>>
>>I used to use this "feature" of passing _SID_ in the query string, but I
>>don't any more.  I wouldn't object to removing it.
>>
>>Another possible implementation would be for HTTPRequest to parse the query
>>string immediately and store in something like self._getFields.  Then the
>>session code could look there.  Of course, you would still lose the
>>"feature" of being able to POST the session ID as a _SID_ field, but I
>>don't know if anyone actually does that.
>>
>>It also might be useful to remember which fields were GET fields and which
>>fields were POST fields and provide some interface for accessing them
>>separately.  I'm thinking of a "smart proxy" situation where you want to
>>gather up the GET and POST fields, perhaps modify or add certain values,
>>then use httplib to forward the modified request to another HTTP server.
>>You can't really do that correctly without being able to access the GET and
>>POST fields separately.
>>
>>- Geoff
>>
>>
>>-------------------------------------------------------
>>This sf.net email is sponsored by:ThinkGeek
>>Welcome to geek heaven.
>>http://thinkgeek.com/sf
>>_______________________________________________
>>Webware-discuss mailing list
>>Web...@li...
>>https://lists.sourceforge.net/lists/listinfo/webware-discuss
>>    
>>
>
>
>
>-------------------------------------------------------
>This sf.net email is sponsored by:ThinkGeek
>Welcome to geek heaven.
>http://thinkgeek.com/sf
>_______________________________________________
>Webware-discuss mailing list
>Web...@li...
>https://lists.sourceforge.net/lists/listinfo/webware-discuss
>  
>