Sdl_evolution: [Accepted] SDL 0200 - Removing URL Parameter Max Length
Hello SDL community,
The review of "SDL 0200 - Removing URL Parameter Max Length" begins now and runs through October 09, 2018. The proposal is available here:
Reviews are an important part of the SDL evolution process. All reviews should be sent to the associated Github issue at:
https://github.com/smartdevicelink/sdl_evolution/issues/603
What goes into a review?
The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of SDL. When writing your review, here are some questions you might want to answer in your review:
- Is the problem being addressed significant enough to warrant a change to SDL?
- Does this proposal fit well with the feel and direction of SDL?
- If you have used competitors with a similar feature, how do you feel that this proposal compares to those?
- How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
Please state explicitly whether you believe that the proposal should be accepted into SDL.
More information about the SDL evolution process is available at
https://github.com/smartdevicelink/sdl_evolution/blob/master/process.md
Thank you,
Jordyn Mackool
Program Manager - Livio
[email protected]
jordynmackool
All 9 comments
I am not sure this proposal is necessary. The current character limit of 1000 characters for a URL is already pretty large, why would you need to use a url that is anywhere near or larger than the character limit?
I think increasing the size would only allow for bad practices.
JackLivio
on 8 Oct 2018
The Steering Committee voted on 2018-10-09 to defer this proposal to allow the author time to respond to this comment and add details on specific use cases where the character limit would need to be so large. It was also agreed that that the author will investigate the max length of a URL that iOS and Android can connect out using their native platform connections, in an effort to agree on a character limit.
jordynmackool
on 10 Oct 2018
So far as I can see, iOS has no real limitations over the size and length of URLs. However, excessively long ones may take a long time to create / parse, and extensive data should be sent via a method that is not a URL (e.g. JSON in the bulk data).
joeljfischer
on 11 Oct 2018
and extensive data should be sent via a method that is not a URL (e.g. JSON in the bulk data).
Agreed, however OEM's sometimes do not have full control over the cloud API's that they are working with (e.g. existing 3rd party cloud API's). If the mobile platforms do not have a url size limitation, I'm not 100% sure if it makes sense to have one in SDL.
mrapitis
on 11 Oct 2018
Adding onto Joel’s comment, so far as I can see it does not seem that Android has feasible limitations on the sizes and lengths of URLs. I believe that the 2000-character limit that was mentioned as common during the call on Tuesday comes from the fact that some web browsers such as Internet Explorer 8 do not permit URLs over 2,048 characters but it seems that this limit has jumped to 81,578 in Microsoft Edge.
Also somewhat relevant facts are:
Section 3.2.1 of RFC 2616 (HTTP/1.1) says “The HTTP protocol does not place any a priori limit on the length of a URI. Servers MUST be able to handle the URI of any resource they serve, and SHOULD be able to handle URIs of unbounded length if they provide GET-based forms that could generate such URIs...”
That RFC has been superseded by RFC7230 which also suggests:”Various ad hoc limitations on request-line length are found in practice. It is RECOMMENDED that all HTTP senders and recipients support, at a minimum, request-line lengths of 8000 octets.”
hypatankar
on 12 Oct 2018
After discussion on this topic, we at Ford Motor Company determined that we cannot share the internal use case which prompted us to request the modification of the URL length parameter.
hypatankar
on 16 Oct 2018
The following was discussed in the Steering Committee meeting on 2018-10-16, with regards to this proposal: Although there are no iOS or Android limitations over the size and length of URLs, excessively long ones may take a long time to create / parse, and extensive data should be sent via a method that is not a URL (e.g. JSON in the bulk data).
Lastly, while it's understood that SDLC members cannot share all use cases for features publicly, it was acknowledged that in the future, when requesting specific features, it is helpful to have real world examples to better understand the reasoning and planned implementation for the requested changes.
jordynmackool
on 17 Oct 2018
JavaScript Suite Issue: https://github.com/smartdevicelink/sdl_javascript_suite/issues/252
theresalech
on 17 Jun 2020
Related issues
theresalech
·
17Comments
theresalech
·
18Comments
jordynmackool
·
7Comments
theresalech
·
6Comments
jordynmackool
·
4Comments
Most helpful comment
Adding onto Joel’s comment, so far as I can see it does not seem that Android has feasible limitations on the sizes and lengths of URLs. I believe that the 2000-character limit that was mentioned as common during the call on Tuesday comes from the fact that some web browsers such as Internet Explorer 8 do not permit URLs over 2,048 characters but it seems that this limit has jumped to 81,578 in Microsoft Edge.
Also somewhat relevant facts are:
Section 3.2.1 of RFC 2616 (HTTP/1.1) says “The HTTP protocol does not place any a priori limit on the length of a URI. Servers MUST be able to handle the URI of any resource they serve, and SHOULD be able to handle URIs of unbounded length if they provide GET-based forms that could generate such URIs...”
That RFC has been superseded by RFC7230 which also suggests:”Various ad hoc limitations on request-line length are found in practice. It is RECOMMENDED that all HTTP senders and recipients support, at a minimum, request-line lengths of 8000 octets.”