Windows Phone Thoughts - Daily News, Views, Rants and Raves

Check out the hottest Windows Mobile devices at our Expansys store!


Digital Home Thoughts

Loading feed...

Laptop Thoughts

Loading feed...

Android Thoughts

Loading feed...




Go Back   Thoughts Media Forums > WINDOWS PHONE THOUGHTS > Windows Phone Talk

Reply
 
Thread Tools Display Modes
  #1  
Old 06-25-2005, 02:26 PM
Menneisyys
5000+ Posts? I Should OWN This Site!
Join Date: Jun 2007
Posts: 5,067
Default A nasty, DST-related bug in all NetFront for PPC versions...

I've found another nasty bug which is NOT fixed in NF 3.2: it doesn't take into account the Daylight Saving Time (DST; please see http://www.timeanddate.com/time/aboutdst.html on DST) when it sends out cookies. (Please also see [url=http://www.pocketpcthoughts.com/index.php?action=expand,41008&/netfront_3.2_english_finally_released.htm]this thread[url] on other old NF bugs that have been fixed in 3.2).

Many web sites issue very short-lived (for example, one hour; an example of them is http://index.hu ) cookies after user log in. The inability to log in to web pages like these is a common complaint with NetFront users. Now, I have had some time to scrutinize the problem and found out that it's certainly NetFront that is buggy - even version 3.2, not just the older versions.

What is exactly the problem?

When a cookie (for example, for authorization) is returned by the HTTP server to the client, a expire attribute is also sent along with it. The latter describes the expiration date/time. It's up to the client to check this time and block sending out the expired cookies when this time elapses.

Web servers (and, incidentally, program libraries like JVM's), don't take the DST into account when constructing messages. That is, during summertime, a Web server will still construct timestamps using winter time. For example, if you're in the GMT time zone (for example, in the UK) and local time is 11:00, a web server that you connect to will still return 10:00 as the current time, even at summer. This causes the problem.

Web clients, including PIE, that know about DST have no problem with this. Clients, however, that don't, do have, especially in cases like receiving very short-lived cookies.

I've written a HTTP answer generator to demonstrate the problem. Its source is available here, and the compiled JAR here.

You can execute the application on both your desktop computer (please read the third post here on doing this) by issuing the

java -jar CookieExpireDateHandlingTester.jar

command, and on your PDA, using either the Jeode, the CrEme or the IBM J9 Personal Java JVM's. (I've tested it with Jeode 1.7.3, CrEme 3.26 and J9 5.7.2). The link files to execute the HTTP server simulator on your PDA's (assuming you already have a Java JVM on your device) can be found here: Jeode, CrEme, IBM J9. Put the JAR file in \conv and click the link file (after modifying it to change the path to your JVM's main .exe). Please note that, unlike with many other Java apps, this server does NOT run under the NetFront application JVM - this is why I have provided no NetFront link files.

Once you have started the server, go to http://127.0.0.1:8081 in your browser (in PIE, you don't need an actual network connection to do this; with NF, you will). This invokes the main page generator code in the server; this routine, among other things, sends over a cookie with an 'expires' attribute. By default, this attribute is set to the current time; this is why the page that the browser will load next (the page that it is redirected to; it, among other things, also displays the test cookie sent back by the browser if present) will not display the cookie message telling that the browser has sent it back.

However, if you supply an additional, numeric parameter to the server in the form of http://127.0.0.1:8081?<value> , you can fine-tune the exact expire time that is sent back to the client. If you use negative integer numbers, then, the cookie will always be valid with a(n in this respect) decent browser; positive numbers (as with not supplying anything), on the other hand, will at once invalidate the cookie (as its expire date equals to or older than the current date). You can also see exactly what time is sent to the client on the JVM console window.

The numeric value you can pass to the server is in minutes; therefore, you will want to test NetFront (and other browsers) a value between 0 and -60 (effectively telling the browser that the cookie should be invalidated in less than an hour) and under -60 (in more than an hour).

With NetFront, if you supply for example -50 (telling it it should invalidate the cookie in 50 minutes), it won't send the cookie to the server any more because it is set back one hour. If you, however, supply -70, then, NetFront thinks the cookie still lives for 10 minutes.

What is the solution? Well, if you want to use NetFront, but just can't log into your favourite site because of these problems, you may want to set back your device's clock with, say, an hour for the time you browse your site. This is not the cleanest solution, but until Access fixes this bug (and, knowing how slow they are, I seriously doubt it will happen in the near future), this is still a working workaround.

You can also play with PC's (or a PPC and a PC) that have different default time zones set to see that this problem is indeed present with not only GMT but also any other time zones. Also, please note that this server is designed to run not just on the local device but on another one too; I've made it localhost-compliant to show how full-fledged Java JVM's are and how powerful the Java language is.
 
Reply With Quote
  #2  
Old 06-26-2005, 08:59 AM
victorypoint
Neophyte
Join Date: Feb 2005
Posts: 2

Have you tried a different user-agent setting (perhaps emulating IE6)?

-AJ
 
Reply With Quote
  #3  
Old 06-26-2005, 09:24 AM
Menneisyys
5000+ Posts? I Should OWN This Site!
Join Date: Jun 2007
Posts: 5,067

Quote:
Originally Posted by victorypoint
Have you tried a different user-agent setting (perhaps emulating IE6)?

-AJ
It won't help: the HTTP server sends the expire attibute using the GMT time without calculating in the DST totally independent of the clien't User-Agent HTTP header. That is, no matter what the client browser is, the HTTP server always sends back the same time.
 
Reply With Quote
  #4  
Old 06-26-2005, 09:32 AM
Menneisyys
5000+ Posts? I Should OWN This Site!
Join Date: Jun 2007
Posts: 5,067

BTW, I've also checked whether pre-3.2 NF versions (3.2 has an encrypted cookie file - this is, security- and privacy-wise, certainly welcome in 3.2 and, in this respect, even better compared to the user-readable cookie format used by most other browsers, including even the desktop-based Internet Explorer - unlike its predecessors; therefore, it can't be read/edited) store cookies that are no longer valid in their NF3.cok file in the home directory.

If they stored them, then, just a simple modification could suffice with a simple text editor. The format of the cookie records in NF is as follows:

Code:
server	path	1	expires	cookie-name	cookie-value
where expires is a simple string formatted in conformance with RFC 1123 (see the http://www.w3.org/Protocols/rfc2616/....html#sec3.3.1 on this). It can be freely edited (as with other parts of this file).

In this case, it doesn't help, though - expired cookies aren't stored.

Bottom line: The only way to make NF work with sites returning cookies that are valid for less than an hour is setting back the PDA clock with at least one hour before visiting the site.
 
Reply With Quote
Reply


Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 09:00 AM.