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.
On Wednesday 30 April 2003 10:38 am, Geoffrey Talvola wrote:
> Terrel Shumway [mailto:tshumway-sf@...] 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.
> Webware-discuss mailing list