Feature proposal: WSRequestFilter to grab headers from resps and use those values at subsequent reqs

[Alexandr Sova]

Hello, Play! framework dev community.

Let me first thank you for that great amount of good job that you did.

I would like to propose a new feature for Play! and discuss is it fits to be available out-of-the-box or is it suits better to be a standalone library. It's a third time when I'm re-creating the same common functionality and I think that I'm not alone in doing same things.

The feature that I'd like to propose is available out-of-the-box WSRequestFilter (further at text: filter or HeadersFilter) implementation (just like AhcCurlRequestLogger is) to handle StandaloneWSRequest (further at text: request) with StandaloneWSResponse (further at text: response) headers in cohesion way at the same place.

Specification:

This new filter should:

• grab headers from response
  
• store grabbed header to some dedicated container (for instance SyncCacheApi based container) to make those values to be accessible by request.url as key
  
• apply stored values to every request that comes with this filter and goes to the same request.url (think string equality would fit enough to decide that header should be applied)
  
• replace header values at container if new response got the same header-keys as previous one did
  

A common use-case: a functionality to get from a web service a content which could be faced as "the same" like static content/files, cached responses, etc.

With this feature implemented developer can use HeadersFilter specialized for ETag and LastModified to store those values at container (for instance cache) and when next request will be formed to go to the same url with this filter it grabs values from container, maps those to If-None-Match and If-Modified-Since respectively and applies to the request.

This way:

• developer of functionality stops thinking about what headers should be added to stop re-download the same giant file again and again, invoking the same file processing instructions again and again and rule data-conflicts, re-submissins with side-effects at those instructions. Developer could just know that he should invoke instructions only if OK response got and there will be no hard data-conflicts because all could be rulled just by apply-latest policy.
  
• web service maintainers would be happy because it's much easier and efficient to just respond NotModified than to respond OK and a giant response body.
  

I'd really appreciate any feedback/criticism on this idea.

Thank you in advance.

[Alexandr Sova]

Also I'd like to propose to move play/api/http/StandardValues.scala to play-ws-standalone. I understand that Play! framework uses those values directly at request/response handling, but Play! framework package requires play-ws-standalone as well. So those values could be moved in backwards-compatible fashion with deprecation of play/api/http/StandardValues.scala file.

вторник, 31 октября 2017 г., 7:11:59 UTC+2 пользователь Alexandr Sova написал:

[Alexandr Sova]

If this idea would be considered ok to have place at Play! framework it would be something like that and separate pull-request to playframework main repo to add RememberedAtSyncCacheHeaders binding to play-ws. Sure, I'll add source file headers and documentation updates just before sending the pull request.

Do anyone have any reasoned opinion should it have place at framework or it shouldn't?