Hacker News new | ask | show | jobs
by cryptonym 4 days ago
Sure you can provide an image as request body, but you could already do it with b64 query parameter. If you try hard enough, you can poorly use any proposed standard. GET with query parameters already is opaque and makes cache busting trivial.
1 comments
layer8 4 days ago
Query parameters are length-limited, because HTTP URIs are: https://www.rfc-editor.org/info/rfc9110/#section-4.1-5. There is no expectation for arbitrarily long HTTP URLs to be functioning.
link
cryptonym 4 days ago
Your link doesn't say URIs are length-limited
link
Draiken 4 days ago
I'm guessing you never hit this issue then, but it's a real issue. Whether or not it's in the RFC as a hard limit it doesn't matter, no HTTP server will allow unlimited sized URIs.

You simply can't base64 large payloads and you're stuck with workarounds.

link
cryptonym 4 days ago
You are guessing wrong. Thanks, I know specific implementation will come with their limits. This will equally apply to QUERY body size and caching strategy.

Are we seriously ok with linking the RFC as source while providing a statement that doesn't match? RFC does matter.

link
ralferoo 4 days ago
The RFC does say "It is RECOMMENDED that all senders and recipients support, at a minimum, URIs with lengths of 8000 octets in protocol elements."

One can infer from the RFC that you can reasonably expect many implementations to fail beyond 8000 characters, and that there are no guarantees up to that either.

True, the RFC doesn't specify a limit, but it does clearly indicate that it's not unbounded, nor should you expect it to be.

link
drdexebtjl 3 days ago
This RFC (10008) does not require caching to be implemented at all, so it would make no sense to make a recommendation here for what is a reasonable limit to expect caching to work.
link
layer8 3 days ago
They are in the sense that the recommended supported length is only 8000 bytes. There are no such specified length recommendations for HTTP body size.
link
cryptonym 3 days ago
Recommended supported length is at least 8k.

Of course I don't advocate oversize URLs. That's a point of RFC10008.

Let's say we build a service for image transformation or image information extraction. Get isn't practical. QUERY with image as body could be a valid usage, regardless of caching. It conveys information that request is idempotent and can be retried with no impact on data, contrary to POST. If your http client is configured to support this, it can potentially improve reliability.

link