Inconsistent GUIDs on RSS feeds served over HTTP vs HTTPS

[johnbillion]

​Originally reported via the maintainer of the Feedbin RSS reader back in 2014 and subsequently fixed, but the issue has re-appeared.

The GUIDs of items in RSS feeds on WordPress.org and WordPress.com appear to be affected by the current scheme, as opposed to using the canonical scheme. This only causes a problem due to persistent caching on .org/.com which causes an HTTP GUID to be served to an HTTPS feed, and vice versa, depending on the luck of the draw when it comes to cache population.

[johnbillion]

cc @joelwills

[dd32]

There shouldn't exist any HTTP-served feeds on WordPress.org at present. The Guids would have unfortunately changed when the HTTP -> HTTPS switch was performed.

Is https://wordpress.org/plugins/rss/browse/new/ the example of a feed that supposedly contains http:// guids? (I'm asking, as I've tried several times bypassing caching and am unable to duplicate)

[johnbillion]

Replying to dd32:

Is https://wordpress.org/plugins/rss/browse/new/ the example of a feed that supposedly contains http:// guids?

Correct. I just visited that URL and the item GUIDs in the feed look like this:

<guid isPermaLink="false">97725@http://wordpress.org/plugins/</guid>

[dd32]

Thanks, I have tried a few more times, and managed to duplicate it.

Oddly enough, I can only duplicate it if I hit an invalid feed URL, such as https://wordpress.org/plugins/rss/browse/new/blahh, something like https://wordpress.org/plugins/rss/browse/new/?blahh doesn't trigger it (no matter how many times you try).
This could be due to the multiple layers of rss caching playing havoc, but it seems pretty reproducible.

[ocean90]

Doesn't seem to be an issue anymore after the bbPress 2.x upgrade and the new plugin directory.