OAI-PMH Support (UXPROD-993)

[EDGOAIPMH-8] OAI-PMH: Response compression Created: 28/Sep/18  Updated: 23/Nov/18  Resolved: 13/Nov/18

Status: Closed
Project: edge-oai-pmh
Components: None
Affects versions: None
Fix versions: 1.0.0
Parent: OAI-PMH Support

Type: Story Priority: P3
Reporter: Hkaplanian Assignee: Viachaslau Khandramai (Inactive)
Resolution: Done Votes: 0
Labels: epam-thunderjet
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Issue links:
Blocks
is blocked by EDGCOMMON-9 EdgeVerticle2: support of HttpServer ... Closed
Relates
relates to UXPROD-350 OAI-PMH Support Closed
relates to MODOAIPMH-53 OAI-PMH: Response Compression (backe... Closed
Sprint: oai-pmh - sprint 50, oai-pmh - sprint 51
Story Points: 2
Development Team: Thunderjet
Epic Link: OAI-PMH Support

 Description   

Official specification: https://www.openarchives.org/OAI/openarchivesprotocol.html#ResponseCompression'

Also see http://www.openarchives.org/OAI/2.0/guidelines-repository.htm#MinimalImplementation-Compression for the implementation guide

  • Default to no compression
  • Only compress responses in accordance with the Accept-Encoding request header
  • Support gzip, compress, deflate
  • Ensure that the supported compression types are advertised in Identify responses
  • When compression is used, return the Content-Encoding response header
  • While it may be trivial to enable the built-in vertx compression functionality, you will still need to create unit tests to ensure it behaves as expected/desired


 Comments   
Comment by Viachaslau Khandramai (Inactive) [ 05/Nov/18 ]

Hi Craig McNally,
according to Core Manual https://vertx.io/docs/vertx-core/java/ Vert.x can handle compressed body payloads which are encoded by the client with the deflate or gzip algorithms only. Could you please clarify do we really need to support compression type compress now?

Thanks,
Slava

Comment by Craig McNally [ 05/Nov/18 ]

Viachaslau Khandramai deflate and gzip are fine for now.

Generated at Fri Feb 09 00:13:41 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.