New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rename Final-Size -> Final-Length #19

Merged
merged 1 commit into from May 1, 2013

Conversation

Projects
None yet
2 participants
@vayam
Copy link
Member

vayam commented May 1, 2013

No description provided.

felixge added a commit that referenced this pull request May 1, 2013

Merge pull request #19 from vayam/master
Rename Final-Size -> Final-Length

@felixge felixge merged commit dd4a798 into tus:master May 1, 2013

@felixge

This comment has been minimized.

Copy link
Contributor

felixge commented May 1, 2013

Thanks for finding / fixing this!

What do you think about the new version overall?

@vayam

This comment has been minimized.

Copy link
Member

vayam commented May 1, 2013

Overall I like it. It is cleaner. I wonder if HEAD request should have Content-Length or Transfer-Encoding
When you add GET later, HEAD and GET responses should match.

@vayam

This comment has been minimized.

Copy link
Member

vayam commented May 1, 2013

And Content-Type header, should we keep it in core protocol and default it to binary/octet-stream.

@felixge

This comment has been minimized.

Copy link
Contributor

felixge commented May 1, 2013

Thanks for the feedback!

I wonder if HEAD request should have Content-Length or Transfer-Encoding

Do you mean for the request or the response?

When you add GET later, HEAD and GET responses should match.

Yes. However, I can imagine different scenarios:

  • Return the Final-Length as the Content-Length. On GET request that means keeping the connection alive until all the data is available (or closing it early to indicate a timeout)
  • Return the Offset as Content-Length and provide clients with the data that's available so far on GET requests. Clients could still "stream" the request by polling / using byte range requests

IMO both are valid options, and should probably be defined as two separate "Download" extensions

And Content-Type header, should we keep it in core protocol and default it to binary/octet-stream.

For requests or responses?

@vayam

This comment has been minimized.

Copy link
Member

vayam commented May 1, 2013

It is weird that email response is all messed up.

Thanks for the feedback!
I wonder if HEAD request should have Content-Length or Transfer-Encoding
Do you mean for the request or the response?

I mean HEAD response.

When you add GET later, HEAD and GET responses should match.
Yes. However, I can imagine different scenarios:
Return the Final-Length as the Content-Length. On GET request that
means keeping the connection alive until all the data is available (or
closing it early to indicate a timeout)

  • Return the Offset as Content-Length and provide clients with the
    data that's available so far on GET requests. Clients could still "stream"
    the request by polling / using byte range requests
    IMO both are valid options, and should probably be defined as two separate
    "Download" extensions

Yeah that works

And Content-Type header, should we keep it in core protocol and default
it to binary/octet-stream.
For requests or responses?

For both

@felixge

This comment has been minimized.

Copy link
Contributor

felixge commented May 3, 2013

About Content-Type: Yeah, I just created #20 to make sure we define a Content-Type for our PATCH requests. The Content-Type for the files themselves will be done as part of the meta extension.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment