[AOLSERVER] ns_httptime format error in AOL 4.5.1
Alexey Pechnikov
As I did find
[ns_httptime 0]
Thu, 1 Jan 1970 00:00:00 GMT
It's wrong! Correct value is "Thu, 01 Jan 1970 00:00:00 GMT". So
cache control by headers "If-Modified-Since" and "If-None-Match"
refused.
Best regards, Alexey Pechnikov.
http://pechnikov.tel/
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to <list...@listserv.aol.com> with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
Tom Jackson
> Hello!
>
> As I did find
> [ns_httptime 0]
> Thu, 1 Jan 1970 00:00:00 GMT
>
> It's wrong! Correct value is "Thu, 01 Jan 1970 00:00:00 GMT". So
> cache control by headers "If-Modified-Since" and "If-None-Match"
> refused.
You can use this as a temporary replacement:
proc ::ns_httptime { seconds } {
return [clock format $seconds -format "%a, %d %b %Y %H:%M:%S %Z" -gmt 1]
}
tom jackson
Alexey Pechnikov
On Saturday 09 May 2009 20:11:11 Tom Jackson wrote:
> You can use this as a temporary replacement:
>
> proc ::ns_httptime { seconds } {
>
> return [clock format $seconds -format "%a, %d %b %Y %H:%M:%S %Z" -gmt 1]
>
> }
Tnx, but AOL internals set wrong header again
Last-Modified: Sat, 9 May 2009 18:07:40 GMT
I did find this error by testing AOL internal caching.
My custom cache function doesn't have the problem:
set mtime [file mtime $fname]
... create gzipped version in cache if needed ...
set none_header [ns_set iget [ns_conn headers] If-None-Match]
set none_header [clock scan $none_header]
set since_header [ns_set iget [ns_conn headers] If-Modified-Since]
set since_header [clock scan $since_header]
if {$none_header == $mtime || $since_header == $mtime} {
ns_return 304 {} {}
return
}
... return original or gzipped file ...
Best regards, Alexey Pechnikov.
http://pechnikov.tel/
Tom Jackson
and the C code uses the same format.
I also used telnet to grab a page from my server running 4.5.0:
tom@boron:~$ telnet rmadilo.com 80
Trying 216.211.130.179...
Connected to rmadilo.com.
Escape character is '^]'.
GET /time.tcl HTTP/1.1
Host: rmadil.com
HTTP/1.1 200 OK
Set-Cookie: SessionID = "6FDD1A4E5EAAF77558F322F3EE041877CB8CFFC2" ;
Max-Age = 809326240 ; Path=/
Set-Cookie2: SessionID = "6FDD1A4E5EAAF77558F322F3EE041877CB8CFFC2" ;
Max-Age = 809326240 ; Path=/ ; Version = 1
MIME-Version: 1.0
Date: Sat, 09 May 2009 20:09:20 GMT
Server: AOLserver/4.5.0
Content-Type: text/plain; charset=UTF-8
Content-Length: 78
Connection: close
time = Sat, 09 May 2009 20:09:20 GMT
zero time = Thu, 01 Jan 1970 00:00:00 GMT
Trying a static file to get a last-modified header:
tom@boron:~$ telnet rmadilo.com 80
Trying 216.211.130.179...
Connected to rmadilo.com.
Escape character is '^]'.
GET /file-time.txt HTTP/1.1
Host: rmadilo.com
HTTP/1.1 200 OK
Set-Cookie: SessionID = "9BD7C5235E14849FB2F81E29510291BD00436734" ;
Max-Age = 809326035 ; Path=/
Set-Cookie2: SessionID = "9BD7C5235E14849FB2F81E29510291BD00436734" ;
Max-Age = 809326035 ; Path=/ ; Version = 1
Last-Modified: Sat, 09 May 2009 20:11:48 GMT
MIME-Version: 1.0
Date: Sat, 09 May 2009 20:12:45 GMT
Server: AOLserver/4.5.0
Content-Type: text/plain; charset=UTF-8
Content-Length: 41
Connection: close
when was this static file last modified?
I'm wondering how your header is generated?
tom jackson
Tom Jackson
> Tnx, but AOL internals set wrong header again
> Last-Modified: Sat, 9 May 2009 18:07:40 GMT
>
> I did find this error by testing AOL internal caching.
I did notice an interesting comment in the C source:
from nsd/httptime.c:
/*
* This will most likely break if the locale is not an english one.
* The format is RFC 1123: "Sun, 06 Nov 1997 09:12:45 GMT"
*/
strftime(buf, 40, "%a, %d %b %Y %H:%M:%S GMT", tmPtr);
So, is your locale set to "an english one"?
Anyone know if the Tcl clock functions are thread-safe?
tom jackson
Rusty Brooks
environment (the tcl Threads library) that make me think they aren't.
> Anyone know if the Tcl clock functions are thread-safe?
Jeff Hobbs
> Anyone know if the Tcl clock functions are thread-safe?
Yes, they are. 8.4 had a few issues earlier on, but 8.5 has a
completely rewritten 'clock' that certainly does away with those issues.
Jeff
Tom Jackson
> On 09/05/2009 1:32 PM, Tom Jackson wrote:
> > Anyone know if the Tcl clock functions are thread-safe?
>
> Yes, they are. 8.4 had a few issues earlier on, but 8.5 has a
> completely rewritten 'clock' that certainly does away with those issues.
How about the latest 8.4 version? Nothing wrong with 8.5, but there are
a few incompatibilities between the two.
This may not be important, my only reason for asking is the potential
problem with a non-english locale, but that seems just as likely to
affect Tcl.
The code comment may just affect the month/day names.
I think Alexey's issue must be coming from some other code path.
tom jackson
Jeff Hobbs
> On Sat, 2009-05-09 at 13:36 -0700, Jeff Hobbs wrote:
>> On 09/05/2009 1:32 PM, Tom Jackson wrote:
>>> Anyone know if the Tcl clock functions are thread-safe?
>> Yes, they are. 8.4 had a few issues earlier on, but 8.5 has a
>> completely rewritten 'clock' that certainly does away with those issues.
>
> How about the latest 8.4 version? Nothing wrong with 8.5, but there are
> a few incompatibilities between the two.
The last known OS thread-safety call issues in 8.4 were with
gethostbyname, et al and corrected for 8.4.14 (Y2006). The checks for
calls like localtime_r have been in since longer. Assuming strftime is
mt-safe, all is ok (the man page is silent on that, but it does print
into a passed in buffer).
> This may not be important, my only reason for asking is the potential
> problem with a non-english locale, but that seems just as likely to
> affect Tcl.
Yes, but indeed 8.5 can control that over the OS level. You mention
incompatibilities - what are they? It should be 100% upwards
compatible, though it has new features. However, it isn't necessarily
100% compatible on the date scan detection, since 8.4- was always
guess-heuristic based, while 8.5 is more deterministic.
Jeff
Tom Jackson
> On 09/05/2009 1:57 PM, Tom Jackson wrote:
> > This may not be important, my only reason for asking is the potential
> > problem with a non-english locale, but that seems just as likely to
> > affect Tcl.
>
> Yes, but indeed 8.5 can control that over the OS level.
Great, I figured this would be the case.
> You mention
> incompatibilities - what are they? It should be 100% upwards
> compatible, though it has new features. However, it isn't necessarily
> 100% compatible on the date scan detection, since 8.4- was always
> guess-heuristic based, while 8.5 is more deterministic.
I was referring to 8.4.x compared to 8.5.x, not just [clock]. I was
thinking that if you upgrade to 8.5.x you needed to do a code review, is
this not necessary?
tom jackson
Dossy Shiobara
>
> The last known OS thread-safety call issues in 8.4 were with
> gethostbyname, et al and corrected for 8.4.14 (Y2006). The checks for
> calls like localtime_r have been in since longer. Assuming strftime is
> mt-safe, all is ok (the man page is silent on that, but it does print
> into a passed in buffer).
I haven't looked at Tcl 8.5 source, but has "clock ... -gmt" been fixed
so that it doesn't diddle with env(TZ) any more, which isn't
thread-safe. I remember that there's Tcl mutexes around the env(TZ)
diddling, but that isn't safe when an application embeds Tcl and
modifies env(TZ) as well but doesn't have access to the mutex that Tcl's
"clock" is using.
I was hoping that newclock addressed this, and newclock is in Tcl 8.5,
right?
--
Dossy Shiobara | do...@panoptic.com | http://dossy.org/
Panoptic Computer Network | http://panoptic.com/
"He realized the fastest way to change is to laugh at your own
folly -- then you can let go and quickly move on." (p. 70)
Jeff Hobbs
> On Sat, 2009-05-09 at 14:14 -0700, Jeff Hobbs wrote:
>> You mention
>> incompatibilities - what are they? It should be 100% upwards
>> compatible, though it has new features. However, it isn't
>> necessarily
>> 100% compatible on the date scan detection, since 8.4- was always
>> guess-heuristic based, while 8.5 is more deterministic.
>
> I was referring to 8.4.x compared to 8.5.x, not just [clock]. I was
> thinking that if you upgrade to 8.5.x you needed to do a code
> review, is
> this not necessary?
Minor version updates should be compatible in Tcl. There is the rare
case of taking what was an error condition and doing something else,
but if you aren't relying on some undocumented private behavior, a
code review isn't required (unless you want to take advantage of newer
features).
Jeff
Tom Jackson
> On 5/9/09 5:14 PM, Jeff Hobbs wrote:
> >
> > The last known OS thread-safety call issues in 8.4 were with
> > gethostbyname, et al and corrected for 8.4.14 (Y2006). The checks for
> > calls like localtime_r have been in since longer. Assuming strftime is
> > mt-safe, all is ok (the man page is silent on that, but it does print
> > into a passed in buffer).
>
> I haven't looked at Tcl 8.5 source, but has "clock ... -gmt" been fixed
> so that it doesn't diddle with env(TZ) any more, which isn't
> thread-safe. I remember that there's Tcl mutexes around the env(TZ)
> diddling, but that isn't safe when an application embeds Tcl and
> modifies env(TZ) as well but doesn't have access to the mutex that Tcl's
> "clock" is using.
>
> I was hoping that newclock addressed this, and newclock is in Tcl 8.5,
> right?
Of course this is why we have abstraction APIs, which are so prominent
in AOLserver. Even if an API is, at an initial point, exactly the same
as the basis API, it is possible, even likely, that changes will be
made. If an abstraction API had been introduced early on, then client
code would remain protected from expected changes. It is hard to explain
the importance of creating a layered API, until you are faced with the
need to change an implementation without changing the client API.
AOLserver is a very good example of planning for future change.
tom jackson
Alexey Pechnikov
On Sunday 10 May 2009 00:32:35 Tom Jackson wrote:
> I did notice an interesting comment in the C source:
> from nsd/httptime.c:
> /*
> * This will most likely break if the locale is not an english one.
> * The format is RFC 1123: "Sun, 06 Nov 1997 09:12:45 GMT"
> */
>
> strftime(buf, 40, "%a, %d %b %Y %H:%M:%S GMT", tmPtr);
>
> So, is your locale set to "an english one"?
My locale is "ru_RU.UTF-8".
Best regards, Alexey Pechnikov.
http://pechnikov.tel/
Gustaf Neumann
set ::env(LANG) C.UTF-8
ns_log notice "START of times [::ns_http_time 0]"
Most likely, it will work as expected
My recommendation is to set the LANG in the startup file.
Maybe, aolserver should force a LANG/LOCALE to avoid
unexpected behavior...
-gustaf neumann
Alexey Pechnikov schrieb:
Alexey Pechnikov
On Sunday 10 May 2009 15:48:21 Gustaf Neumann wrote:
> Try in an aolserver script:
>
> set ::env(LANG) C.UTF-8
> ns_log notice "START of times [::ns_http_time 0]"
>
> Most likely, it will work as expected
>
> My recommendation is to set the LANG in the startup file.
> Maybe, aolserver should force a LANG/LOCALE to avoid
> unexpected behavior...
It's bad because russian strings in scripts and from databases wll be corrupted.
Dossy Shiobara
> On Sunday 10 May 2009 15:48:21 Gustaf Neumann wrote:
>> Try in an aolserver script:
>>
>> set ::env(LANG) C.UTF-8
>> ns_log notice "START of times [::ns_http_time 0]"
>
Alexey,
Have you confirmed this through empirical testing? There is a
difference between the locale that the system libc functions use (i.e.,
env(LANG)) vs. what AOLserver's encoding is set to (through the config
.tcl ns_params).
It might be worth investigating as to whether setting the system locale
and properly configuring the AOLserver encoding (need a good HOWTO on
this) will behave for you.
--
Dossy Shiobara | do...@panoptic.com | http://dossy.org/
Panoptic Computer Network | http://panoptic.com/
"He realized the fastest way to change is to laugh at your own
folly -- then you can let go and quickly move on." (p. 70)
Alexey Pechnikov
On Sunday 10 May 2009 20:05:24 Dossy Shiobara wrote:
> On 5/10/09 9:59 AM, Alexey Pechnikov wrote:
> > On Sunday 10 May 2009 15:48:21 Gustaf Neumann wrote:
> >> Try in an aolserver script:
> >>
> >> set ::env(LANG) C.UTF-8
> >> ns_log notice "START of times [::ns_http_time 0]"
This return bad result too:
"Notice: START of times Thu, 1 Jan 1970 00:00:00 GMT"
> Alexey,
>
> Have you confirmed this through empirical testing? There is a
> difference between the locale that the system libc functions use (i.e.,
> env(LANG)) vs. what AOLserver's encoding is set to (through the config
> .tcl ns_params).
Any UTF-8 locale is correct for non-english languages support. For example I can use
en_US.UTF-8. (Note: PostgreSQL user account must have utf8 locale!) I did have some
problems with old AOL versions but now this work fine. I'm prefer to start AOL with
ru_RU.UTF-8 because executing of external application may need in russian locale.
Best regards, Alexey Pechnikov.
http://pechnikov.tel/