HeaderResultMatchers susceptible to slight variations in the date format [SPR-17330]

[spring-projects-issues]

cfloersch opened SPR-17330 and commented

So the server now appears to format HTTP date headers using a single or double digit DAY depending on the time of month. However, the HeaderResultMatchers.dateValue() still uses a two digit DAY zero padded if necessary when doing the matching.

This results in test failing 100% when run between the 1st and 9th of any given month.

Both dates should use the same format. Or better yet the matcher should operate on Date objects rather than formatted strings.

Example build failure

[ERROR] Failures:
[ERROR] SimpleControllerTest.testGetCustomHeader:152 Response header 'Last-Modified' expected:<Wed, 03 Oct 2018 17:56:00 GMT> but was:<Wed, 3 Oct 2018 17:56:00 GMT>

---

Affects: 5.0.9

Attachments:

• DateFailure.zip (6.00 kB)

Referenced from: commits b89cb20, 658c7f9

Backported to: 5.0.10

[spring-projects-issues]

Rossen Stoyanchev commented

Both dates should use the same format. Or better yet the matcher should operate on Date objects rather than formatted strings.

The response header is a string at that point, so either the input long should be formatted too, or the response header needs to be parsed. We can use HttpHeaders to do either one of those and that way it should be consistent.

[spring-projects-issues]

Rossen Stoyanchev commented

Sorry, but I'm having trouble reproducing the issue.

I can see that HttpHeaders formats and stores dates as you indicated. However, when ResponseEntity.ok().lastModified(..).body(..) is returned from the controller, that goes through MockHttpServletResponse#setDateHeader which formats with a 2 digit day. That explains why tests like these have not failed.

Can you provide instructions or sample code how to reproduce the issue?

[spring-projects-issues]

cfloersch commented

I attached a sample app. It appears that if the Last-Modified header is set using Headers.setDate(String, long) from a ResponseAdvice you can reproduce the issue. Using ResponseEntity does not produce the issue.

[spring-projects-issues]

Rossen Stoyanchev commented

Okay so it all depends on whether the header is set on the MockHttpServletResponse as a String or a long in which can result in slightly different formats. As there is nothing wrong with 2 digits for the day, I've opted to improve the checks in HeadersResultMatchers to parse the actual header which can be done more leniently and accept slightly differences like that.

[rstoyanchev]

Note that there was a fix in Spring MVC Test #21864 to make it more lenient in this regard.