Hi @rhessinger ,
we have finally found time to install the update and validate the fix you made.
We can confirm that everything is working as expected now.
Short remark which we realised while testing: HEAD requests still do not send the Last-Modified header, while GET requests do. This might be by intention, but I thought I'd share this.
Thanks for your help with this!
This is great news, thanks for the super good feedback and fast responses! Looking forward to the next release 
This actually looks a little supsicious, but it's hard to tell without knowing what this.Cache actually is. Is this code kind of "general" to all requests in ProGet or is it specific to Assets? For assets I would have expected for the Last-Modified header to get it's value from the asset itself and not from any cache - but again, I don't know enough about your code base to really comment on this.
The spec on Date however is pretty clear (https://www.rfc-editor.org/rfc/rfc9110.html#section-6.6.1) that this header is not related to the actual content but more about when the response was generated. This information is very rarely of much interest tbh.
Last-Modified however is directly related to the date and time when the content of the requested document (file in this case) has changed.
@atripp Thanks for your answer. I checked the caching options before posting here, but they don't really help in this case. Unfortunately Jenkins does not support the ETag header (and the other caching options). The whole implementation is based around the Last-Modified header.
See the implementation here for reference:
https://github.com/jenkinsci/jenkins/blob/5f7a4ee04e7a28bfb97805f2e5829ea0cd3f1c9c/core/src/main/java/hudson/FilePath.java#L980
The conditional requests RFC (7232) also states
An origin server SHOULD send Last-Modified for any selected
representation for which a last modification date can be reasonably
and consistently determined, ...
I understand that the platform is responsible for responding to cache request headers. The Last-Modified header however is not something that is a response to a certain given request header but needs to simply be returned. Only the If-Modified-Since header is one, that the server has to actively responde to (and ProGet rightfully does so already).
Anyways, I guess our question simply is: Is it reasonable for you to (re-)add this header in a future version? It feels like a simple change, as the asset UI already shows this exact field.
(If it helps anything, we are actually a paying customer, just chose to use the forum instead of a support incident).
Thanks,
Philipp
We use the Asset feature to host ZIP files for use as "Jenkins Custom Tools".
Long story short, Jenkins uses the Last-Modified header on the original download of a file to identify whether to send the "If-Modified-Since" header for future requests to the same file.
We are pretty sure, that earlier versions of ProGet did actually return this header, as we have files on Jenkins slaves (back from april 2021) which have the correct modified header set.
Somewhere between back than and today (we update our instance pretty regular), this must have changed, as any request to the asset files in ProGet no longer return the Last-Modified header. This is a kind of a major problem for us, because Jenkins is downloading the same files over and over again.
Was this change by intention and is there any way to get this enabled again? The only change in your releases notes which might be remotely connected to this topic is this
https://inedo.myjetbrains.com/youtrack/issue/PG-2068
Thanks for your help!
Dear Indeo,
while the promotion and re-packaging features look very promising, they seem to lack one important feature that I'd imagine alot of people have in real life scenarios:
Pushing (Promoting and / or Repackacing) Software from something like build => prerelease => rc => production is not a matter of doing it for a single package but probably doing so for many many packages including their dependencies.
We have a pretty big tree of internal (nuget) dependencies coming together from various projects.
Here is a sample of what I mean:
WPF Application => Services.dll => Domain.dll => EntityFrameworkShared.dll + Extensions.dll + Logging.dll
We name our packages something like "1.0.0-build.1234" where "1234" is simply the build number.
All of these DLLs are actually self-contained NuGet packages built from our build-server and pushed into ProGet.
Now, when the WPF Application is going to be tested, we'd like to generate a whole tree of all those dependencies labeled as "-prerelease".
And after testing we'd like to move the whole tree into the production state where all packages do not have any prelease tag at all.
So coming together, I guess I have two questions:
Thanks for you help!
Philipp