Errors in HTML on APOD site

[sasha]

Hi!

I tried emailing Mr. Nemiroff, but he dismissed the fact that lately HTML code for the daily images on APOD is incorrect for the video entries. That makes my Android live wallpaper app really unhappy

Here is an example:

2013 August 19
<br>
<iframe width="960" height="540" src="//www.youtube.com/embed/E7PQbfnErEw?rel=0" frameborder="0" allowfullscreen></iframe>
</center>

Notice that http: is missing, making the URL malformed:
macbookpro:~ curl //www.youtube.com/embed/rFDjAfwmWKM?rel=0

curl: (3) <url> malformed

I hope more people complain, so he fixed the HTML

Thanks,
.a

[RJN]

Thanks for your concern. I used the *exact* html embed code given by YouTube when "embed" is chosen. I worry that if I change that embed code even by a few letters -- even letters that seem they obviously should be included -- then other browsers may have trouble understanding it. And I can't test every browser scenario to be sure. Also, unfortunately, so far, you are the only one to complain about this. I assume that YouTube has done its homework and provides the optimal embed code. I am sorry if it is causing you trouble. Please email YouTube and then tell us here on the Asterisk their reply. - RJN

[geckzilla]

Your worries are unfounded. Someone at YouTube must have goofed. The http: definitely needs to be included. The iframe should read:

Code: Select all

<iframe width="960" height="540" src="http://www.youtube.com/embed/E7PQbfnErEw?rel=0" frameborder="0" allowfullscreen></iframe>

There is possibly a problem with determining whether or not it wants to give you a secure (https) or normal (http) protocol so somehow no protocol got prepended. It fails to include an http: for me as well. That's pretty odd. I am almost positive it must be a bug that slipped by.

[RJN]

Someone at YouTube must have goofed.

If true, this is one big goof! It seems likely true of every embedded YouTube code, which must number in the hundreds every day. Could someone do us a favor find a web page documenting this goof? If so, please post it here and I will change the APOD html, and YouTube should definitely be informed. - RJN

[geckzilla]

I asked a few people and finally have discovered that leaving the protocol off allows the browser to decide which to use. However, since APOD is always served unsecured, it would definitely not hurt to add the http: on the front. It's up to you whether or not you care enough to have sasha's apparently poorly written Android app function.

Here's a short article detailing a protocol-relative URL: http://www.paulirish.com/2010/the-proto ... ative-url/

[Chris Peterson]

Someone at YouTube must have goofed.

If true, this is one big goof! It seems likely true of every embedded YouTube code, which must number in the hundreds every day. Could someone do us a favor find a web page documenting this goof? If so, please post it here and I will change the APOD html, and YouTube should definitely be informed. - RJN

There are a number of sites out there documenting the error. Nothing from Google that I find; nobody understands why this change occurred, or why it hasn't been fixed. But all agree that the fix is to add the http protocol reference to the link (or two links in some cases).

BTW, if you right-click the video and select 'Copy embed code' you get the correct version. It's only when you use the separate embed button that the broken version gets generated.

[geckzilla]

It's not technically wrong even though it's causing some problems, though. I have to rescind my statement about being positive it's a bug. It's intended to stop those pop-up warnings about loading insecure content while viewing things from a secured website. Undoubtedly they did it because they receive a lot of complaints from frightened people over that (the warning box is rather unnerving). Since a lot of people who publish web content don't actually know what they are doing, it made sense for YouTube to solve it in this manner instead of, say, adding an option for a secure embed code which merely adds an s to the end of http.

I must emphasize the fact that as long as APOD is always being served through http, using http for all embeds will never cause any problems and might actually avoid some for some individuals.

[Chris Peterson]

It's not technically wrong even though it's causing some problems, though.

It is technically wrong. In this context, the SRC attribute requires an absolute URI, so you must include the scheme name, in this case 'http:' or 'https:'. As it is, the URI is malformed. Some browsers will silently repair this by assuming 'http:', but they are not required to do so. Depending on that isn't very good design.

The engineers at Google really ought to be smart enough to come up with a more elegant solution.

[sasha]

I asked a few people and finally have discovered that leaving the protocol off allows the browser to decide which to use. However, since APOD is always served unsecured, it would definitely not hurt to add the http: on the front. It's up to you whether or not you care enough to have sasha's apparently poorly written Android app function.

Here's a short article detailing a protocol-relative URL: http://www.paulirish.com/2010/the-proto ... ative-url/

Thanks for the vote of confidence. Rest assured, my app functions according to the RFC 3986. For your reference, here is a relevant part:
http://tools.ietf.org/html/rfc3986#section-1.1.1:

Each URI begins with a scheme name, as defined in Section 3.1, that refers to a specification for assigning identifiers within that scheme.

My app is not a web browser.

Regards,
.a

[sasha]

Thanks for your concern. I used the *exact* html embed code given by YouTube when "embed" is chosen. I worry that if I change that embed code even by a few letters -- even letters that seem they obviously should be included -- then other browsers may have trouble understanding it. And I can't test every browser scenario to be sure. Also, unfortunately, so far, you are the only one to complain about this. I assume that YouTube has done its homework and provides the optimal embed code. I am sorry if it is causing you trouble. Please email YouTube and then tell us here on the Asterisk their reply. - RJN

Thanks for the reply!

It appears that always adding http: won't be harming anything - in fact that's how it was for years until recently.

Btw, here is what YouTube gave me when I clicked 'copy embed code' in a video:
<iframe width="640" height="360" src="https://www.youtube.com/embed/ig7lA9ERw ... detailpage" frameborder="0" allowfullscreen></iframe>

Please, notice the https: is present there (copied from Chrome on Windows, with HTTPS Everywhere extension enabled).

Here is the code copied using IE on Windows:
<iframe width="640" height="360" src="http://www.youtube.com/embed/ig7lA9ERwA ... r_embedded" frameborder="0" allowfullscreen></iframe>

http: is present.

We must be copying using different methods.

Thanks for your reply and consideration,
.a

[geckzilla]

I asked a few people and finally have discovered that leaving the protocol off allows the browser to decide which to use. However, since APOD is always served unsecured, it would definitely not hurt to add the http: on the front. It's up to you whether or not you care enough to have sasha's apparently poorly written Android app function.

Here's a short article detailing a protocol-relative URL: http://www.paulirish.com/2010/the-proto ... ative-url/

Thanks for the vote of confidence. Rest assured, my app functions according to the RFC 3986. For your reference, here is a relevant part:
http://tools.ietf.org/html/rfc3986#section-1.1.1:

Each URI begins with a scheme name, as defined in Section 3.1, that refers to a specification for assigning identifiers within that scheme.

My app is not a web browser.

Regards,
.a

Oh? Emphasis mine. Perhaps I'm misunderstanding it, but the very document you link to indicates that the use of relative referencing is permitted.

It is often the case that a group or "tree" of documents has been
constructed to serve a common purpose, wherein the vast majority of
URI references in these documents point to resources within the tree
rather than outside it. Similarly, documents located at a particular
site are much more likely to refer to other resources at that site
than to resources at remote sites. Relative referencing of URIs
allows document trees to be partially independent of their location
and access scheme. For instance, it is possible for a single set of
hypertext documents to be simultaneously accessible and traversable
via each of the "file", "http", and "ftp" schemes if the documents
refer to each other with relative references. Furthermore, such
document trees can be moved, as a whole, without changing any of the
relative references.

Just defining "authority component" here. I think it's referring to the http:, https:, ftp:, file:, etc. This is a bit more than I ever cared to know about URI syntax.

The authority component is preceded by a double slash ("//") and is
terminated by the next slash ("/"), question mark ("?"), or number
sign ("#") character, or by the end of the URI.

Finally,

If a URI contains an authority component, then the path component
must either be empty or begin with a slash ("/") character. If a URI
does not contain an authority component, then the path cannot begin
with two slash characters ("//"). In addition, a URI reference
(Section 4.1) may be a relative-path reference, in which case the
first path segment cannot contain a colon (":") character.

[RJN]

OK. Got it. Thanks everyone -- very interesting! I just added "http:" to the html code. - RJN

[sasha]

OK. Got it. Thanks everyone -- very interesting! I just added "http:" to the html code. - RJN

Thank you very, very much!!!