Bug in HTTP header

EVE Technology and Research Center Third Party Developers
1

Time format in HTTP responses did not meet the standard rfc2068.
See https://esi.tech.ccp.is/latest/status/?datasource=tranquility

Response Headers:
{
“date”: “Wed, 08 Nov 2017 06:03:18 GMT”,
“via”: “1.1 google”,
“status”: “200”,
“alt-svc”: “clear”,
“content-length”: “80”,
“x-esi-error-limit-remain”: “100”,
“last-modified”: “08 Nov 2017 06:02:59 GMT”,
“x-esi-error-limit-reset”: “42”,
“access-control-max-age”: “600”,
“access-control-allow-methods”: “GET,OPTIONS”,
“content-type”: “application/json”,
“access-control-allow-origin”: “*”,
“access-control-expose-headers”: “Content-Type,Warning”,
“cache-control”: “public”,
“access-control-allow-credentials”: “true”,
“access-control-allow-headers”: “Content-Type,Authorization,X-User-Agent”,
“expires”: “08 Nov 2017 06:03:29 GMT”
}

Error in last-modified and expires.

2

It’s funny that date is actually compliant, but the others aren’t.

3

The correct date format
"date”: “Wed, 08 Nov 2017 06:03:18 GMT

Indicating the day of the week.
See RFC2068 standard (http://www.ietf.org/rfc/rfc2068)
3.3 Date/Time Formats

4

The standard for date is rfc2822.

5

No.

“This standard specifies a syntax for text messages that are sent
between computer users, within the framework of 'electronic mail’
messages. This standard supersedes the one specified in Request For
Comments (RFC) 822, “Standard for the Format of ARPA Internet Text
Messages”, updating it to reflect current practice and incorporating
incremental changes that were specified in other RFCs…”

This standard for EMail.

6

Doesn’t in any way change the fact that this is the format used.

7

Actually the same format is defined in various RFC, and the header is re-specified in rfc7231, which is based on rfc5322 which is based on rfc2822.

8

See the rfc2616 standard.
This is the standard for HTTP/1.1.

9

The problem remained. The Functions Of The WindowsAPI.

WinHttpTimeToSystemTime
and
WinHttpQueryHeaders(hRequest, WINHTTP_QUERY_LAST_MODIFIED | WINHTTP_QUERY_FLAG_SYSTEMTIME, WINHTTP_HEADER_NAME_BY_INDEX, &Time, &Size, WINHTTP_NO_HEADER_INDEX)

not work.

10

7231 obsoleted 2616 but that’s not the point. Esi uses 2822 - this in fact is correct with 7231 which de facto allows any format, but prefers a subset of 5322. You just need to deal with it.

11

Yesterday everything was fine.

This BUG.

12

Today also everything is working fine, just not how you assume it should. Now you have 2 options:

  • Keep arguing this is invalid, at which point you will be proven false by simply quoting the RFC, and your code will continue to not work.
  • Accept reality and fix your stuff - use a date library which can handle this.
13

WindowsAPI not work.

Thank you. I’ll deal with my code itself.
Goodbye.

14

09 Nov 2017.
Fixed

{
“strict-transport-security”: “max-age=31536000”,
“via”: “1.1 google”,
“status”: “200”,
“alt-svc”: “clear”,
“content-length”: “80”,
“x-esi-error-limit-remain”: “100”,
“last-modified”: “Thu, 09 Nov 2017 05:56:39 GMT”,
“date”: “Thu, 09 Nov 2017 05:56:40 GMT”,
“x-esi-error-limit-reset”: “20”,
“access-control-max-age”: “600”,
“access-control-allow-methods”: “GET,OPTIONS”,
“content-type”: “application/json”,
“access-control-allow-origin”: “*”,
“access-control-expose-headers”: “Content-Type,Warning”,
“cache-control”: “public”,
“access-control-allow-credentials”: “true”,
“access-control-allow-headers”: “Content-Type,Authorization,X-User-Agent”,
“expires”: “Thu, 09 Nov 2017 05:57:09 GMT”
}

15

Just in case, fyi as it may interest you (or someone else): http/1.1 headers are supposed to follow this rfc
RFC 7231 - Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content which is the one ESI uses iirc (at least, that’s what I were replied on the esi github).

I also believe it was a bug, but please, next time you get such problem, you’d better report it on github instead of the forum, it will be fixed faster

I think what you state is wrong: rfc 7231 allows format from rfc5322 (what they call the “prefered format”) and obsolete format from RFC 850 and from asctime, but that’s all.
It doesn’t allow “any” format, actually it says the contrary:

A recipient that parses a timestamp value in an HTTP header field
MUST accept all three HTTP-date formats. When a sender generates a
header field that contains one or more timestamps defined as
HTTP-date, the sender MUST generate those timestamps in the
IMF-fixdate format.

But anyway, it’s looks like it’s fixed, so it doesn’t matter :wink:

16

Well, if you want a full investigation then here you go :slight_smile:

5322 is a newer version of 2822, but the date/time format is the same. If we then get to 7231, we can see:

Recipients of timestamp values are encouraged to be robust in parsing
timestamps unless otherwise restricted by the field definition. For
example, messages are occasionally forwarded over HTTP from a
non-HTTP source that might generate any of the date and time
specifications defined by the Internet Message Format.

Translation: the format can be anything than the preferred one - deal with it.

17

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.