Last modified: 2011-11-25 06:32:56 UTC
I tried to do "<rss max="6">//blog.wikimedia.org/feed/</rss>" at <https://wikimediafoundation.org/wiki/Template:Blogbox> and it produced the error "Not a valid URL: //blog.wikimedia.org/feed/". The RSS extension should support protocol-relative URLs, I think?
Protocol-relative doesn't really have meaning here; the feed is fetched from the server-side code and cached, so would be fetched the same way from: * web hits to http * web hits to https * server-side batch processing You should either use the http or the https URL.
(In reply to comment #1) > Protocol-relative doesn't really have meaning here; the feed is fetched from > the server-side code and cached, so would be fetched the same way from: > > * web hits to http > * web hits to https > * server-side batch processing > > You should either use the http or the https URL. I was trying to make the output flexible based on the user's current protocol. Is there no way to do that? Should there be?
Does the output of <rss> even include the original URL?
(In reply to comment #3) > Does the output of <rss> even include the original URL? I don't know. I tried looking at the code, but I couldn't figure out where the list items were being put together. If you use an https:// input link, you get https:// output. I think supporting protocol-relative output in the RSS extension for blogs that support https and http is reasonable here.
If // is used as the protocol in the extension tag, we could rewrite URLs returned by the feed to be protocol relative before outputting them. But every URL in a feed may not be on the same domain as the feed. Unless every one of those URLs is on the same domain, we can't be sure they actually support both protocols. If the feed is on a different domain than the content of the feed (such as with Planet Wikimedia, FeedBurner, etc.), the protocols we can use to access that content are a mystery. We can tell from the URL that we can use one of http:// or https://, but we don't know if we can use both unless we check.
