Hoss Man created HADOOP-14115:
---------------------------------
Summary: SimpleDateFormatter's are construted w/default Locale,
causing malformed dates on some platforms
Key: HADOOP-14115
URL: https://issues.apache.org/jira/browse/HADOOP-14115
Project: Hadoop Common
Issue Type: Bug
Reporter: Hoss Man
In at least one place I know of in Hadoop, {{SimpleDateFormatter}} is used to
serialize {{Date}} object in a format intended for machine consumption -- and
should be following strict formatting rules -- but the {{SimpleDateFormatter}}
instance is not constructed with an explicit {{Locale}} so the platform default
is used instead. This causes things like "Day name in week" ({{E}}) to
generate unexpected results depending on the Locale of the machine where the
code is running, resulting in date-time strings that violate the formatting
rules.
A specific example of this is {{AuthenticationFilter.createAuthCookie}} which
has code that looks like this...
{code}
Date date = new Date(expires);
SimpleDateFormat df = new SimpleDateFormat("EEE, " +
"dd-MMM-yyyy HH:mm:ss zzz");
df.setTimeZone(TimeZone.getTimeZone("GMT"));
sb.append("; Expires=").append(df.format(date));
{code}
...which can cause invalid expiration attributes in the {{Set-Cookies}} header
like this (as noted by http-commons's {{ResponseProcessCookies}} class...
{noformat}
WARN: Invalid cookie header: "Set-Cookie: hadoop.auth=; Path=/;
Domain=127.0.0.1; Expires=Ara, 01-Sa-1970 00:00:00 GMT; HttpOnly". Invalid
'expires' attribute: Ara, 01-Sa-1970 00:00:00 GMT
{noformat}
There are very likely many other places in the hadoop code base where the
default {{Locale}} is being unintentionally used when formatting Dates/Numbers.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: common-dev-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-dev-h...@hadoop.apache.org
