You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This discussion exists to talk about whether the Path Send spec can be reasonably modified to support offset and count, in a similar manner to those respective variables within zerocopysend.
On the backward compatibility thing, I personally think is fine to add new features on top of an existing extension, given there's a way for the application to understand if those features are supported.
One idea might be to add this information to the scope, eg:
in such way the application knows if the server supports the additional keys in the messages and use them; the lack of that boolean means no support is given. I'd also personally prefer a single key in the message for the range, as the application should already know the total size of the file to produce valid range headers, eg:
{
"type": "http.response.pathsend",
"path": "foobar.txt",
"range": (0, 4096) # send only the first 4KB
}
This discussion exists to talk about whether the Path Send spec can be reasonably modified to support
offset
andcount
, in a similar manner to those respective variables withinzerocopysend
.As a summary of the original discussion...
zerocopysend
was effectively dead on arrival due to integration challenges with existing webservers.pathsend
can be considered as an alternative that is more compatible with a variety of webservers.pathsend
currently does not supportoffset
andcount
, which makes it impossible to use with HTTP range requests.andrewgodwin
agreed thatoffset
andcount
can be added topathsend
if it can be implemented in a backwards compatible mannerhttp.response.pathsend2
The text was updated successfully, but these errors were encountered: