Last-Modified HTTP header of assets contained in jar is wrong when using sbt >= 1.4.0

[bchazalet]

Play Version

2.7.7

API

Scala

Operating System

macosx but will affect all I believe

JDK

Seen on OpenJDK 15 and Oracle Java 8

Library Dependencies

Sbt 1.4.4

Expected Behavior

1. Package a play application using universal:packageZipTarball and sbt >= 1.4.0
2. Deploy the application
3. Send a GET request for one of the static asset
4. Inspect the last-modified response header and assert that it aligns with when you packaged the application in step 1

Actual Behavior

1. Package a play application using universal:packageZipTarball
2. Deploy the application
3. Send a GET request for one of the static asset, say
4. Inspect the last-modified response header: depending on your platform the last modified header will either be set to 1 Jan 1970 or 7 February 2106 (which known to be a common time storage issue).

---

We've tracked down the issue to this sbt change: https://github.com/sbt/sbt/pull/5344. Basically, sbt now resets file timestamps in jars to 1970-01-01. And that date is in turn used by the play framework to set the last-modified header. You can double check by unpacking the jar yourself, jar fx your-assets-jar.jar and inspecting the dates on the filesystem.

One fix to this is to set an environment variable to the current time when building and packaging the play application, e.g.:

export SOURCE_DATE_EPOCH=`date +%s`

I don't know if this should be fixed by the framework itself, but I think it should at least be documented as it will (and did for us) cause cache issues.

[zekronium]

@vietj It should be good for review and open for changes if needed

[vietj]

@zekronium for now it is on hold until HTTP/3 is part of Netty 4.2 branch

[zekronium]

@vietj Why not have it as an optional dependency. Might take while, whilst other projects are already using it such as netty reactor

[He-Pin]

Do you have some numbers to share? we tested HTTP/3 for internal networking (internal RPC) and it shows it performant bad than HTTP/2,

[vietj]

@imz87 I had to make some internal changes, you should rebase this branch over latest master

[imz87]

@imz87 I had to make some internal changes, you should rebase this branch over latest master @vietj , sure, I'll rebase my branch onto the latest master.

[imz87]

Do you have some numbers to share? we tested HTTP/3 for internal networking (internal RPC) and it shows it performant bad than HTTP/2,

@He-Pin I haven't tested HTTP/3 against anything yet, so I don't have any numbers or statistics to share at this time. I just added Http3Test.java, which is similar to Http2Test.java and serves as a kind of unit test.

[imz87]

@imz87 I had to make some internal changes, you should rebase this branch over latest master @vietj , sure, I'll rebase my branch onto the latest master.

@vietj , I just rebased onto the latest master.

[imz87]

Hi @vietj ,

I noticed that there's a NetSocket implementation for HTTP/2, and it seems to be used for WebSocket as well. Is something similar required for HTTP/3? Specifically, would we need a WebSocket based on an HTTP/3 connection?

Thanks, Iman

[vietj]

See https://github.com/netty/netty/issues/14739

[vietj]

@imz87 yes this is needed, the main use case is HTTP CONNECT that tunnels a NetSocket.

[imz87]

@imz87 yes this is needed, the main use case is HTTP CONNECT that tunnels a NetSocket.

Ok, thanks for your response.

[indiealexh]

Looking forward to this so I can switch from websockets to http3 streams.

[imz87]

Looking forward to this so I can switch from websockets to http3 streams.

Great to hear! We're excited for you to try it out.

[vietj]

@imz87 can you rebase this to laster master ?

[imz87]

@imz87 can you rebase this to laster master ?

@vietj It's done!

[indiealexh]

https://github.com/netty/netty/pull/14979 🎆

[zekronium]

netty/netty#14979 🎆

Still need http3 codec