On Sun, 14 Aug 2005, marcus saw wrote:
> I do agree that the URL rewriting can cause problems when... as one of
> our clients recently did, actually advertised as part of the URL in a
> mailshot.
Woah!
>However, this can be, for most situations, worked around by setting the
>session timeout to something quite short, like 15 minutes and ensuring
>the server flushes all the user specific data regularly; and by using a
>sufficiently long and random session ID.
What I've been doing is keeping a copy of the user-agent in my session
object, and checking it with every request. If the user agent changes,
I kill the session. That will make sure that, in many cases at least,
if someone gives someone else a URL within their 20-odd-minute session
time, they still won't take over the session.
This did nail me once when someone installed a WebDAV client (probably
FrontPage) that was going and makeing OPTION requests that gave back the
same cookies, but with a different user-agent, but I worked around that
by just 400'ing all OPTION requests, since I have no intention at the
moment to use WebDAV on tabemo.com.
> You did say in the wiki that URL rewriting is a lot of work, I had the
> luxury of using PHP to automate this process so didn't have to edit
> / write any code but if you are using Java with something like the
> Websphere app server then yeah there is a little bit more work to do.
Actually, a bunch of my old code is PHP, but I still had to do a lot
of work. The issues were the automatic choice between URL rewriting
and cookies (using cookies when you can, and rewriting when you have
to), and the more important one was not rewriting the URLs themselves,
but just the BASE tag in the header, to keep page size down and allow
developers and HTML folks to use more-or-less ordinary URLs in pages.
> One thing I am not sure about, from a practical point of view, is
>whether or not the extra characters needed in the URL to hold the
>session ID really will cause problems in terms of extra file size.
In terms of being able to display pages, probably not. Even 30 rewritten
URLs in a page is going to add only about 1/3 KB to it, which is not
even 10% of Docomo's 5KB maximum page size on the older phones.
But I don't agree that the extra packet charges are negligible. That
1/3 KB is three extra packets, which is almost an extra yen per page
browse for Docomo users. Someone visiting your site every other day and
browsing a dozen pages (which is certainly not unusual for tabemo.com)
could incuur a couple of hundred extra yen in packet charges due to
that, which is more than half the monthly price of our service itself.
> As for the original question you posted about the cookie being
> dropped on AU, I read from that last link I sent that only some
> phones actually hold the cookie on the handset and the rest hold it
> on the server. So that would explain why, when you open the secure
> port directly to the handset only some phones would have the original
> cookie information on the handset.
Ah, I see! Well, now the problem makes sense. However, I'm not sure that
newer phones fix this; a Casio phone released this year still has the
same problem.
> Well as a result of your posts I would now like to explore the
>cookies on AU more as its likely that the other carriers will start
>implementing them soon.
I don't know about that. Docomo is now on its fifth version of their
markup language, and they've introduced Flash even, but they still don't
have a single phone that returns cookies.
But doing rewriting all the time to avoid the work of automatic
switching is quite a reasonable approach, if you don't mind the other
problems that brings. We have a lot of users on PC browsers as well, so
it's probably not such a good idea for us, but if you're mostly mobile,
it's not such a big deal.
cjs
--
Curt Sampson <cjs@cynic.net> +81 90 7737 2974
*** Contribute to the Keitai Developers' Wiki! ***
*** http://www.keitai-dev.net/ ***
Received on Sun Aug 14 10:36:04 2005