Validation of https URLs fail with error

[tabacha]

I have got the following error:
column 0: url must be a full URL: https://files.opsluten.de/ops003.opus
But it is a full url. Every secure https file is marked like this.

Check this bug, with the following feed:
https://opsluten.de/feed/opus

Best Regards
Sven Anders

[timpritlove]

ye olde story. feedvalidator denies the existence of https.

[tkrotoff]

+1

[rubys]

If you would like RSS to support https content, ask the author of RSS to change the spec. See also: #12 (comment)

[tabacha]

http://www.rssboard.org/rss-specification#comments said:

Prior to RSS 2.0, the specification only allowed http:// and ftp://

RSS 2.0.11 allows https?!?

[rubys]

Um, the people on that board were "sold a Brooklyn Bridge". See http://scripting.com/2006/02/17.html

Dave Winer is still active. If you wish to get the spec to change, I encourage you to contact him.

[nickcernis]

@rubys I emailed Dave Winer to ask about adding https to the spec. He replied that it's fine to also accept https wherever http is currently accepted.

I wrote:

Would you be willing to update the RSS 2.0 spec to accept https as well as http URIs?

Popular feed validators such as http://feedvalidator.org/ currently mark feeds as invalid if they contain enclosures or links to podcast art that begins 'https'.

They're unwilling to correct this until the RSS 2.0 spec changes to accept 'https': #12

Dave kindly replied:

1. When I write blog posts, they are just blog posts, not spec text.
2. Same with emails. This is not spec text, it's just an email.
3. In my opinion of course you can use https where ever you would use http.

Given that this is the case, please could feedvalidator accept https URIs?

[rubys]

First, Dave didn't answer your question. While he gave an opinion that contradicted other posted opinions, he explicitly stated that this email isn't spec text.

Second, the feed validator is open source. If you don't like what the spec says, feel free to write your own spec and validator for that spec based on this source. Furthermore, if you follow the instructions in the RSS spec to name your spec something other than RSS, I will gladly consider accepting patches to support that spec too.

[nickcernis]

Thanks for the reply and offer to accept patches, Sam.

I'm interested in seeing https support in the feed validator for several reasons:

1. Site owners use the feed validator to verify that their feed won't cause problems for RSS readers and third-party services such as iTunes. The “must be a full URL” error is confusing because:

   • (a) the resources are full URLs that are accessible to all user agents;
   • (b) consumers of feeds that can access resources over http can also access https ones – the validator is not identifying any underlying issue that needs fixing;
   • (c) unlike other problems that the validator identifies, the “must be a full URL” error is often not actionable if the only reason for the URL being invalid is that it starts with https. Users of hosted services that use site-wide SSL frequently can't drop back to http for their feeds only, as the generated feed is outside of their control. (They can fix errors in the content, but not how that content is referenced.)

   These issues may become more common as site-wide SSL grows in popularity with Let's Encrypt, and as hosted services switch to SSL-by-default. The feed validator will tell these site owners that their feed is broken when it is not.

2. Apple's support team uses the feed validator to diagnose feed problems and assess whether or not to accept a podcast feed into iTunes. They have cited “must be a full URL” errors caused by https as the reason for a feed being rejected, even though the feed is otherwise fully valid.

I understand that a contributor could fork the validator, but I'm not certain that this would fix the problems I've outlined above. And, while someone could create their own spec called “notRSS” just to allow enclosures that start with https, perhaps it's a waste of resources to fabricate a largely duplicate spec, maintain it, and expect the feed validator team to review and continue to support it.

I also realise that you'd like to adhere to the spec word-for-word, but if the goal of the feed validator is to allow site owners to check for errors that could cause issues for RSS readers, perhaps it's worth adapting to real-world use cases and considering feedback from active users.

Even if the 2.0 spec isn't quite so quick to update or explicit about allowing 'https' as well as 'http', it's clear that its creator intends resources referenced with https to pass, that users of the feed validator expect that behaviour too, and that user agents have no problem with it either. For those reasons, https resources should pass as valid.

[rubys]

if the goal of the feed validator is to allow site owners to check for errors that could cause issues for RSS readers

The existence of a single popular feed consumer, or indeed the existence of any number of feed consumers, that support https is not evidence that all feed consumers support https.

I can provide any number of citations that indicate that the author of RSS's intention was and remains explicitly NOT to support RSS. I can also provide a number of citations that indicate that such intention has not remained constant over time.

You are making a good case that the spec should be updated. Or that an alternate spec should be used instead. Go make that happen, and once that is done, this feedvalidator will be updated to match.