| yuvipanda | |
| Feb 24 2014, 8:05 PM |
| F12849: Screenshot_2014-03-26-03-48-36.png | |
| Nov 22 2014, 2:51 AM |
https://en.wikipedia.org/w/api.php?action=mobileview&format=json&page=10_dollar_note§ions=2-&prop=text should return zero sections, since I am asking for sections '2-' and there is only a section 0 on that page. Instead I get all sections + 2 empty sections
Version: unspecified
Severity: enhancement
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | None | T64721 The lead section is duplicated with section heading "undefined" in articles with only a lead section | |||
| Resolved | None | T63868 action=mobileview shouldn't return sections when the range of sections asked for is out of range |
bingle-admin wrote:
Prioritization and scheduling of this bug is tracked on Mingle card https://wikimedia.mingle.thoughtworks.com/projects/mobile/cards/1727
It seems like this should throw an error saying invalid arguments (sections should either be a number of the keyword all)
I'd say this is super super low priority - a good patch for a new developer to MobileFrontend to take care of?
It actually affects the app - since we don't know clientside how many sections there are, I can't just not send the second request. So this should either send an error message or no sections, rather than false data.
It seems we are saying the same thing? I'm suggesting error message. Why are you not using sections=all any reason?
Not using section=all because reduces data transfer? And it's not super duper low priority since all pages with only one section produce errenous data and the app displays those as it is supposed to (see attachment). Hence this is something I'd like Max (or myself? :P) to fix ASAP, not 'super low priority bug for volunteer months from now'
(OT: Would an 'API' component make sense for MF?)
(In reply to Jon from comment #2)
It seems like this should throw an error saying invalid arguments (sections
should either be a number of the keyword all)
action=mobileview has been accepting ranges for a few months now in sections= :)
Data transfer vs number of http requests. With Gzip encoding is amount of dat really an issue? Have you benchmarked this?
If this is accepting ranges it is not well documented. The documentation says this which is not clear at all how this is expected to work - is this all except the last section or something else?:
Ranges without second number, e.g. '1-' means get all until the end.
Change 121410 had a related patch set uploaded by MaxSem:
mobileview: handle requested sections outside of range
Change 121410 merged by jenkins-bot:
mobileview: handle requested sections outside of range
