Skip to content
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

Range header should parse Range-Units other than 'bytes' #177

Open
ltvolks opened this issue Nov 25, 2014 · 0 comments
Open

Range header should parse Range-Units other than 'bytes' #177

ltvolks opened this issue Nov 25, 2014 · 0 comments
Labels

Comments

@ltvolks
Copy link
Contributor

ltvolks commented Nov 25, 2014

The Range header parsing regex requires that the range be specified as bytes, e.g. bytes = 10-20
The only defined range unit is "bytes" according to RFC2616#3.12, but other range units are allowed.

My use case is to not have to maintain custom header parsing code when using the Range header for pagination requests. Currently a Range header like items = 10-20 will not match.

It is not uncommon to see services defining pagination using a series of Range requests (see Heroku's API, Dojo toolkit, Angular PaginateAnything)

ltvolks added a commit to ltvolks/webob that referenced this issue Nov 25, 2014
- Range units other than 'bytes' may be provided as part of a Range
  or Content-Range header
- Updated __repr__() tests for Range and ContentRange to actually test
  the return value of the repr call (previous test was only asserting
  that __repr__() returned a 'truthy' value)
- Updated Range repr to return a string representation enclosed in angle
  brackets, matching the style of most other WebOb classes
  (vs. a string that may be able to be passed to `eval`)
- Fixes Pylons#177
ltvolks added a commit to ltvolks/webob that referenced this issue Nov 25, 2014
- Range units other than 'bytes' may be provided as part of a Range
  or Content-Range header
- Updated __repr__() tests for Range and ContentRange to actually test
  the return value of the repr call (previous test was only asserting
  that __repr__() returned a 'truthy' value)
- Updated Range repr to return a string representation enclosed in angle
  brackets, matching the style of most other WebOb classes
  (vs. a string that may be able to be passed to `eval`)
- Fixes Pylons#177
ltvolks added a commit to ltvolks/webob that referenced this issue Nov 25, 2014
- Range units other than 'bytes' may be provided as part of a Range
  or Content-Range header
- Updated __repr__() tests for Range and ContentRange to actually test
  the return value of the repr call (previous test was only asserting
  that __repr__() returned a 'truthy' value)
- Updated Range repr to return a string representation enclosed in angle
  brackets, matching the style of most other WebOb classes
  (vs. a string that may be able to be passed to `eval`)
- Fixes Pylons#177
ltvolks added a commit to ltvolks/webob that referenced this issue Nov 25, 2014
- Range units other than 'bytes' may be provided as part of a Range
  or Content-Range header
- Updated __repr__() tests for Range and ContentRange to actually test
  the return value of the repr call (previous test was only asserting
  that __repr__() returned a 'truthy' value)
- Updated Range repr to return a string representation enclosed in angle
  brackets, matching the style of most other WebOb classes
  (vs. a string that may be able to be passed to `eval`)
- Fixes Pylons#177
ltvolks added a commit to ltvolks/webob that referenced this issue Nov 25, 2014
- Range units other than 'bytes' may be provided as part of a Range
  or Content-Range header
- Updated __repr__() tests for Range and ContentRange to actually test
  the return value of the repr call (previous test was only asserting
  that __repr__() returned a 'truthy' value)
- Updated Range repr to return a string representation enclosed in angle
  brackets, matching the style of most other WebOb classes
  (vs. a string that may be able to be passed to `eval`)
- Fixes Pylons#177
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants