Menneisyys
06-25-2005, 02:26 PM
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 this thread 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 (http://www.pocketpcthoughts.com/index.php?action=expand,41008&/netfront_3.2_english_finally_released.htm) ) 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 (http://www.winmobiletech.com/062005DSTProblemInNFCookieHandling/CookieExpireDateHandlingTester.java), and the compiled JAR here (http://www.winmobiletech.com/062005DSTProblemInNFCookieHandling/CookieExpireDateHandlingTester.jar).
You can execute the application on both your desktop computer (please read the third post here (http://www.pocketpcthoughts.com/forums/viewtopic.php?t=41049) 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 (http://www.winmobiletech.com/062005DSTProblemInNFCookieHandling/Jeode.lnk), CrEme (http://www.winmobiletech.com/062005DSTProblemInNFCookieHandling/CrEme.lnk), IBM J9 (http://www.winmobiletech.com/062005DSTProblemInNFCookieHandling/J9.lnk). 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 [url]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 [url]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.
Many web sites issue very short-lived (for example, one hour; an example of them is http://index.hu (http://www.pocketpcthoughts.com/index.php?action=expand,41008&/netfront_3.2_english_finally_released.htm) ) 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 (http://www.winmobiletech.com/062005DSTProblemInNFCookieHandling/CookieExpireDateHandlingTester.java), and the compiled JAR here (http://www.winmobiletech.com/062005DSTProblemInNFCookieHandling/CookieExpireDateHandlingTester.jar).
You can execute the application on both your desktop computer (please read the third post here (http://www.pocketpcthoughts.com/forums/viewtopic.php?t=41049) 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 (http://www.winmobiletech.com/062005DSTProblemInNFCookieHandling/Jeode.lnk), CrEme (http://www.winmobiletech.com/062005DSTProblemInNFCookieHandling/CrEme.lnk), IBM J9 (http://www.winmobiletech.com/062005DSTProblemInNFCookieHandling/J9.lnk). 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 [url]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 [url]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.