Can't get Content-Length info with HEAD request

[bugrayaktiyol]

Describe the bug

Hello there, I am using OSV-API query/querybatch endpoints on my project to get vulnerability list.
I was able to get Content-Length through HEAD request like a week ago.
Now, I'm getting 400 Bad Request when I try to send a HEAD request to get Content-Length.
I was building a system to compare between POST request and HEAD request of given endpoints. content-lengths.
I don't know if it's a bug but I think I was able to get HEAD request response header a week ago.

To Reproduce
Steps to reproduce the behaviour:

1. Creating a POST request with https://api.osv.dev/v1/querybatch
2. Setting sample body like this

{
  "queries": [
    {
      "package": {
        "purl": "pkg:pypi/[email protected]"
      }
    },
    {
      "commit": "6879efc2c1596d11a6a6ad296f80063b558d5e0f"
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "jinja2"
      },
      "version": "2.4.1"
    }
  ]
}

3. Getting Content-Length = 3863 on response Header.
4. Creating a HEAD request with https://api.osv.dev/v1/querybatch with the previous sample body.
5. Getting 400 Bad Request.
   Expected behaviour
   Getting Content-Length = 3863 info on Header response just like POST request without response body.

Screenshots

POST

HEAD

Additional context
If HEAD request was not a feature and service has been removed, is there any chance to bring it back again?
Thank you.

[andrewpollock]

I'm not aware of there being any recent functional changes to the API that would have caused this behaviour change. Are you sure you were making HEAD requests for what would have otherwise been POST requests? That is not consistent with my understanding of how HTTP requests work, based on https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods/HEAD

[another-rex]

Are you referring to the ability to:

For example, if a URL might produce a large download, a HEAD request could read its Content-Length header to check the filesize without actually downloading the file.

(From the mdn link)

[bugrayaktiyol]

@andrewpollock

I'm not aware of there being any recent functional changes to the API that would have caused this behaviour change. Are you sure you were making HEAD requests for what would have otherwise been POST requests? That is not consistent with my understanding of how HTTP requests work, based on https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods/HEAD

Hello there, thank you for answer. Actually yes, reffering as from the mdn link: For example, if a URL might produce a large download, a HEAD request could read its Content-Length header to check the filesize without actually downloading the file.

It also says
Request has body | No
I think it's what I am doing wrong.

There is no ETag so how can I be able to get Content-Length with request body and without response body is what I'm wondering actually.

I am working with big queries, so I was trying to build a caching system to check for recent changes in identifying vulnerabilities in multiple versions of numerous dependencies.

After sending POST requests to query batches and getting vulnerability reports, I wanted to check if there were any changes in those versions without sending another POST request.

Instead, I planned to send a HEAD request to get the Content-Length. If the Content-Length of the previous POST request is equal to the Content-Length of the HEAD request, it would indicate that the response bodies of the two requests are the same. I am not sure if I am missing something else.

@another-rex

Are you referring to the ability to:

For example, if a URL might produce a large download, a HEAD request could read its Content-Length header to check the filesize without actually downloading the file.

(From the mdn link)

Yes, this is exactly the functionality I am looking for. Is it feasible, or am I missing something?

[andrewpollock]

Disclaimer: I have only done very superficial research into this to refresh my dated understanding of the HTTP protocol.

My understanding is that HTTP POST requests are generally not cachable. To make them cachable would be new API functionality and would require maintaining a server-side cache of the results of the exact set of inputs, which seems like it would have a very low probability of broad cache hits (obviously, for someone like yourself repeatedly requerying with the same inputs, it might).

Could you please file a new API feature request issue with the following information to allow us to prioritise:

• what your general use case is
• example API usage that indicates the size of your queries and the size of the results
• discusses how caching would be of a benefit (e.g. lower bandwidth costs, less repetitive client-side processing of unchanged data, reduced client-side complexity)

If I've missed something, feel free to reopen and add more context, otherwise please file a fresh issue per above.