Project

General

Profile

Actions
Copy link

Bug #11274

open

Static resource and suggestFileName

Added by Emeric Poupon almost 2 years ago. Updated almost 2 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Target version:
-
Start date:
01/24/2023
Due date:
% Done:

0%

Estimated time:

Description

Hello,

I am not sure about static WResource and suggestFileName()
For a REST application, I need to react from different URL parameters and set up a filename based on the parameters. This is very likely to change for each request.
I guess a static WResource can be handled concurrently by multiple threads? If it is the case, then it does not work and I have to write myself the Content-Disposition header in the response. Maybe it would be more relevant to add a suggestFileName() method on Http::Response then?

Actions
Copy link
 #1

Updated by Dries Mys almost 2 years ago

I agree that such a method (i.e. Http::Response::suggestFilename()) would be useful. However this seems to me rather a feature request than a bug.

Another use case of setting the filename inside the handleRequest handler is when you want to include a kind of timestamp in the filename.

Actions
Copy link
 #2

Updated by Emeric Poupon almost 2 years ago

Dries Mys wrote in #note-1:

I agree that such a method (i.e. Http::Response::suggestFilename()) would be useful. However this seems to me rather a feature request than a bug.

Another use case of setting the filename inside the handleRequest handler is when you want to include a kind of timestamp in the filename.

Well that is why I was not sure. If a static resource can be handled in // by several threads, then there is a bug since multiple threads calling suggestFileName() on the same WResource will likely produce garbage or crash.
Is that the case?

Actions
Copy link
 #3

Updated by Roel Standaert almost 2 years ago

I'd say it's not so much a bug as it is a limitation, which we may need to document a bit better.

The following setters should not be used concurrently, and not after the resource was exposed:

  • WResource::setTakesUpdateLock(...)
  • WResource::suggestFileName(...)
  • WResource::setDispositionType(...)

The following setters should not be used concurrently (if they are attached to a specific WApplication then you should have that WApplication's UpdateLock:

  • WResource::setUploadProgress(...)
  • WResource::beingDeleted() (should be called in the destructor of a specialized WResource)
  • WResource::setInternalPath(...)
  • WResource::setChanged()
  • WResource::setInvalidAfterChanged(...)
  • WResource::setInternalPath(...)
  • WResource::generateUrl()

The following can be safely used concurrently or should be implemented when the resource is specialized so that they can be safely used concurrently:

  • WResource::haveMoreData()
  • WResource::write(...)
  • WResource::handleRequest(...) (will be called whenever this is a request)
  • WResource::handleAbort(...) (will be called when a request is aborted)
Actions
Copy link

Also available in: Atom PDF