|Regarding https support for youtube embeds||Fredrik Jönsson||8/28/11 11:47 PM|
It would have been nice if the embed-service, when requested over https, responded with https-urls in the resulting snippet, instead of us having to assume things and rewrite them afterwards.
|Re: Regarding https support for youtube embeds||Jeffrey Posnick||8/29/11 12:58 PM|
You're talking about the oEmbed service, detailed here, right?
I agree that it would make sense to return HTTPS URLs in that
scenario. I'll put in a feature request with the Players team about
-Jeff Posnick, YouTube API Team
groups.google.com/group/youtube-api-gdata | apiblog.youtube.com |
|Re: Regarding https support for youtube embeds||Fredrik Jönsson||8/30/11 12:05 PM|
Yes, I should have been more clear on that, sorry. Thanks for the
|Re: Regarding https support for youtube embeds||Jeffrey Posnick||9/30/11 11:40 AM|
For various reasons, the team decided that having the URL scheme of
the oEmbed request determine whether to return HTTP or HTTPS URLs in
the response wasn't the right approach. Some of this has to do with
the oEmbed standard's documented behavior, and the team will be
following up with the folks responsible for oEmbed with some feedback
In the meantime, though, there's a new "scheme=https" URL query
parameter that should be supported starting next Wednesday evening. If
you include it in your requests, you're explicitly telling the oEmbed
service that you'd like to get back URLs that use HTTPS.
|Re: [YouTube-API] Re: Regarding https support for youtube embeds||bertb||9/30/11 12:49 PM|
Are we to assume, therefore, that the default is "scheme=http", even though you've not indicated that this is a valid oembed URL query parameter?
And to ward off the negative impact for iOS apps, of a future switch to making "scheme=https" the default (similar to the recent decision to change the default of "iframe=0" to "iframe=1"), should not the "scheme=http" URL query specification also be introduced on Wednesday so that we can specify "scheme=http" in our iOS apps if we choose to keep this "default" in place?
G. Bert Bonkowski
Founder, Screenius Inc.
|Re: Regarding https support for youtube embeds||Jeffrey Posnick||10/3/11 11:01 AM|
It's correct to assume that the default scheme is still "http", and
yes, on Wednesday you can start using "scheme=http" to force that on
the chance that we change to defaulting to "https" at some point in
the future. (There are no plans to do so that I'm aware of at this
|Re: [YouTube-API] Re: Regarding https support for youtube embeds||bertb||10/4/11 6:52 AM|
Perhaps I'm being too subtle.
Identifying a variable's starting value as a "default" in any official document means that it will always be that value if another value is not explicitly set in some way.
If you are going to change the starting values of variables (like iframe or, perhaps in the future, scheme) that aren't explicitly specified, then you cannot call those values "defaults".
Doing so sends the wrong message.
|Re: [YouTube-API] Re: Regarding https support for youtube embeds||Tim Wintle (Guru)||10/4/11 6:57 AM|
On Tue, 2011-10-04 at 09:52 -0400, bert bonkowski wrote:
I don't read the word "default" in the same way - to me a default is
|Re: [YouTube-API] Re: Regarding https support for youtube embeds||bertb||10/4/11 7:41 AM|
So, what is the point of identifying what a parameter's default value is, if not to simply use its default value when it turns out to be appropriate?
As you suggest, and has been proven by YouTube several times recently (iframe, 3d), the "default" value certainly can't be depended upon to remain that way.
And, following through, if a new parameter is introduced whose implicit starting value has any possibility of changing in the future, it should not be documented as having a default value.
Instead, perhaps, the new parameter should be documented as requiring an explicit setting and "strict" should complain if that new parameter doesn't exist. But this introduces another gotcha in that existing apps become broken just because a new parameter was introduced into the API.
So, clearly, we developers have no choice but to explicitly specify parameter values for parameters we need to care about - whether we realize it or not - such a 3d, scheme, or iframe. And, we need to upgrade our apps in the field just because a new parameter introduced by an API might change from the default value that is appropriate for apps already in the field.
|Re: Regarding https support for youtube embeds||Fredrik Jönsson||10/19/11 11:50 AM|
We are using this new feature in our site since last week and it is
greatly appreciated since we can avoid most of our mixed-content
issues. Tanks a lot and send my regards to the team.
> For various reasons, the team decided that having the URL scheme of> the oEmbed request determine whether to return HTTP orHTTPSURLs in
> the response wasn't the right approach. Some of this has to do with> > > I agree that it would make sense to returnHTTPSURLs in that
> > > scenario. I'll put in a feature request with the Players team about> > > > responded withhttps-urls in the resulting snippet, instead of us having to