Streamline GetObject #494

New issue

Closed

opened 2025-12-28 17:37:35 +00:00 by sami · 0 comments

sami commented

2025-12-28 17:37:35 +00:00

Owner

Originally created by @roman-khimov on GitHub (Feb 25, 2025).

Originally assigned to: @smallhive on GitHub.

I'm always frustrated when I'm looking at GetObject logic. It has huge potential for improvement. Currently is works this way:

SEARCHes for an appropriate object via searchAllVersionsInNeoFS()
HEADs it in headVersion()
processes headers for various purposes
SEARCHes for tagging object (most of the time it's not present)
SEARCHes for locking object (most of the time it's not present)
forms and writes response header
makes RANGE request and pipes the payload

Describe the solution you'd like

One search for everything. One get for everything. The only exception is range-based requests since there it'd be HEAD+RANGE, but these are minority obviously. It's all totally possible because:

the first search has to check for the same tagging and locking objects, it's just that we're losing this data for whatever reason and doing TWO more searches to get it again
HEAD can be avoided because it is possible to issue a GET request and get the same header for free effectively and then pipe the payload from the same request

Originally created by @roman-khimov on GitHub (Feb 25, 2025). Originally assigned to: @smallhive on GitHub. ## Is your feature request related to a problem? Please describe. I'm always frustrated when I'm looking at GetObject logic. It has huge potential for improvement. Currently is works this way: * SEARCHes for an appropriate object via `searchAllVersionsInNeoFS()` * HEADs it in `headVersion()` * processes headers for various purposes * SEARCHes for tagging object (most of the time it's not present) * SEARCHes for locking object (most of the time it's not present) * forms and writes response header * makes RANGE request and pipes the payload ## Describe the solution you'd like One search for everything. One get for everything. The only exception is range-based requests since there it'd be HEAD+RANGE, but these are minority obviously. It's all totally possible because: * the first search has to check for the same tagging and locking objects, it's just that we're losing this data for whatever reason and doing TWO more searches to get it again * HEAD can be avoided because it is possible to issue a GET request and get the same header for free effectively and then pipe the payload from the same request