403 Problem w/beta 19

An RSS/Atom newsreader with features comparable to commercial newsreaders.
Post Reply
asm
Harmless
Posts: 2
Joined: Thu Nov 28, 2013 2:30 pm

403 Problem w/beta 19

Post by asm »

I have a feed on my website which Vienna is failing on with a HTTP 403 - even though when I "Show XML Source" it's there and looks fine. I can access the feed directly in a browser and I can validate it fine, but Vienna (Version 3.0.0 Beta 19 :40267c3:) doesn't want to read it. Any suggestions on how to track down the problem?
  • My site is a Wordpress site.
  • I did not update or change anything on it recently.
  • I noticed the problem after updating to Vienna Version 3.0.0 Beta 19.
  • I just checked on another machine and Beta 18 reads it fine.
My site: http://asmaloney.com
My Feed: http://asmaloney.com/feed
Validation: http://feedvalidator.org/check?url=http ... .com/feed/

Thanks for any help!

- Andy
aperantos
Harmless
Posts: 18
Joined: Tue Feb 08, 2005 1:31 am
Location: London, UK

Re: 403 Problem w/beta 19

Post by aperantos »

I have the same problem accessing http://www.londonreconnections.com/feed/ which is also a wordpress site. I have downgraded back to beta 18 which can still access it.
Echelon9
Latté
Posts: 74
Joined: Sun May 19, 2013 12:45 am

Re: 403 Problem w/beta 19

Post by Echelon9 »

Thanks for the report (and clear reproduction steps), we'll take a look at it.
asm
Harmless
Posts: 2
Joined: Thu Nov 28, 2013 2:30 pm

Re: 403 Problem w/beta 19

Post by asm »

Great, thanks! If you need anything else from me, or need me to try anything, please just let me know.

- Andy
Echelon9
Latté
Posts: 74
Joined: Sun May 19, 2013 12:45 am

Re: 403 Problem w/beta 19

Post by Echelon9 »

I'm tracking through this bug in Github Issue #235.

The cause is some complex processing of the User-Agent field by a Wordpress plugin called Bad Behaviour which Wordpress.com use.

The change to "Mozilla/5.0 Vienna/Master Safari/537.71" in our Vienna user-agent between Beta 18 and Beta 19 -- which was required to ensure Google's servers would correctly produce gzip encoded content -- is tripping one of Bad Behaviour's string or regex blocks.

So it's some combination of characters in the new user-agent which the Bad Behaviour plugin matches is causing this.
Echelon9
Latté
Posts: 74
Joined: Sun May 19, 2013 12:45 am

Bad Behaviour Wordpress plugin problems w/beta 19

Post by Echelon9 »

From Github Issue #235

Summary

Fundamentally, Bad Behaviour is filtering based on incorrect assumptions made about the HTTP standards.

I've tried reporting this in the Bad Behaviour bug tracker system with no luck so far, and will be looking to their developer to fix it in an upcoming release.

In the mean time we should inform Vienna users that they have subscribed to a server which uses the Bad Behaviour plugin, and request the host contacts the developer of Bad Behaviour to have its code fixed.

Technical details

Bad Behaviour plugin requires the use of an Accept HTTP header when certain strings are contained in the User-Agent, whereas the RFC 2616 clearly states Accept header is optional.
The "Accept" header field can be used by user agents to specify
response media types that are acceptable. Accept header fields can
be used to indicate that the request is specifically limited to a
small set of desired types, as in the case of a request for an in-
line image.
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html
http://tools.ietf.org/html/draft-ietf-h ... tion-6.3.2

Further technical details can be found at Github Issue #235
Post Reply