_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:tshumway-sf@jdiworks.net] 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
Webware-discuss@lists.sourceforge.net
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
Webware-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/webware-discuss