-
-
Notifications
You must be signed in to change notification settings - Fork 30.7k
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
Add support for RTMP schemes to urlparse #60338
Comments
|
Please add support in urlparse for the family of RTMP schemes: I believe these schemes should be added to the following module variables: The RTMP spec is hosted at http://www.adobe.com/devnet/rtmp.html which describes the format as "protocol://servername:port/" An example YouTube RTMP *service* URL looks like: Please let me know if further information is required. Thanks! ======================================== A full YouTube RTMP stream URL may look like this: rtmp://a.rtmp.youtube.com/videolive?ns=yt-live&id=123456&itag=35&signature=blahblahblah/yt-live.123456.35 i.e. it is the stream service url suffixed with '/' + the_stream_name. When one uses urlparse (extended with the 'rtmp' scheme), the stream name part gets lumped in with the last query value. |
|
As this is a feature request, it can only be applied to 3.4. I've modified the versions. |
|
Personally, I want to do away with all those scheme specific stuff, if we can. I have tried previously, but failed due to some backwards incompatibility. 3.4 gives a good chance/time to make those changes to get rid of those scheme specific stuff (again). So, instead of adding the rmtp* modules to the various categories, I would like to see if can find a way out. bpo-9374 - another related one which. Also, Jorge Gomes: If you care about 2.7 version only, then the way I have seen this issue being handled in production is you extend the uses_relative list with the protocols that you want to support.
2.7.x is in bugfix mode and this change may not be considered a bug-fix to find it's place in 2.7.x |
|
bpo-9374 - another related one which should be taken care. Which is simply reverting this: http://hg.python.org/cpython/diff/a0b3cb52816e/Lib/urllib/parse.py and informing in the DOCs that those globals are not available anymore. (But this should also be discussed in python-dev before making the change). |
|
i'd like to see a proposed change against the 3.4 standard library for this with tests. |
|
Looks like bpo-9374 already covers most of this, with fixes in 2.7, 3.2 and 3.3. $ python3.3
Python 3.3.2 (default, May 16 2013, 23:40:52)
[GCC 4.6.3] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from urllib.parse import urlparse
>>> urlparse("protocol://servername:port/")
ParseResult(scheme='protocol', netloc='servername:port', path='/', params='', query='', fragment='')
>>> urlparse("rtmp://a.rtmp.youtube.com/videolive?ns=yt-live&id=123456&itag=35&signature=blahblahblah/yt-live.123456.35")
ParseResult(scheme='rtmp', netloc='a.rtmp.youtube.com', path='/videolive', params='', query='ns=yt-live&id=123456&itag=35&signature=blahblahblah/yt-live.123456.35', fragment='')Now there are only the three unresolved aspects listed below, as I see it. Personally I think the first, for urljoin(), should be fixed (hopefully in a generic way without whitelists). I mentioned this in bpo-18828. I wonder if last two really matter?
|

Formed in 2009, the Archive Team (not to be confused with the archive.org Archive-It Team) is a rogue archivist collective dedicated to saving copies of rapidly dying or deleted websites for the sake of history and digital heritage. The group is 100% composed of volunteers and interested parties, and has expanded into a large amount of related projects for saving online and digital history.

Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: