Solutions-Nitriques/oembed_field

Error 503 issues

Closed this issue · 20 comments

Hi Nitriques, is the extension sending any info about user agent at all with the request? http://vimeo.com/forums/topic:29419

We've been getting the same error on all attempts to build and save entries in a section using oembed and I'm wondering whether Vimeo are trying to limit requests and the post above points to some user agent requirements when sending a request.

Any thoughts?

Also mentioned here too: http://hwdmediashare.co.uk/forum/26-problems-hwdvs/38456-vimeo--503-service-unavailable-solved#38547 could this be something that needs fixing in the driver?

Humm... this is a strange issue...

I am not sure about the limit thing: To be blocked, you would have to send A LOT of request to vimeo and this extension only sends one on each save...

About the UA, I thought that Sym was setting it to Sym/2.2.3 or somthing like that, but my assumptions may be false.

I need to work on this extension today as I need a MySpace Driver (yes the oembed community is getting bigger!) I will check on the UA issue.

I do not run Symphony locally. If you do, please install a web proxy like Fiddler to sniff what if going between Sym and Vimeo.

Ok cool, I'm on it today so I'll keep you posted. The youtube one works fine still.. 2.2.2. and 2.2.3 install so you know.

Here's a HTTP request output from Firefox's LiveHTTPHeaders add-on.

REMOVED DATA DUE TO IRRELEVANCE.

The entry itself is created but no values are entered due to the error 503 symphony error page appearing after clicking the save/edit entry. I see no Symphony UA data in the header info: I'm on a mac using Firefox, Chrome and Safari and my colleagues are n PC using FF and Chrome.. all report same error.

Your are not spying the right connection. We need to find a way to spy between your apache server and vimeo's server, not between your browser and your apache....

I seems like it's working as normal on my end, so the UA settings should not be an issue. But it would be nice to be sure...

Ok, proxy sniffing on mac? any thoughts?

Try Charles... but I don't know if there is a free version....

If not maybe there is a distro of Squid for Mac OS...

Ok cool, Found a free version of Proxy Sniffer Console and am installing me workspace locally to test. There does seem to be issues with banning IP's when there are too many requests for the same video/user on Vimeo, but like you said about, It would need to be a lot of requests. We were doing 10 in an hour to test embedding and it didn't even work then.

Hum... Except the 503 code, to you get any more error details ?

10 requests an hour is not enough....

Weirdly I'm getting a 404 error now.

'''
DOMDocument::load(http://vimeo.com/api/oembed.xml?url=http://vimeo.com/27543915) [domdocument.load]: failed to open stream: HTTP request failed! HTTP/1.1 404 Not Found
'''

On a local install using Xampp my ensemble installed fine and I am able to update the video section with new oembed entries.. so not sure why I'm getting errors on the staging domain.

Hum... This page http://vimeo.com/api/oembed.xml?url=http://vimeo.com/27543915 is working on my end...

We're you able to sniff the request made by the ext ?

No not yet, the localhost install is working, not sure how I'd sniff the staging host.

Just looked at a recent log and this is the entry:
15 September 2011 19:59 > UNKNOWN: DOMDocument::load(http://vimeo.com/api/oembed.xml?url=http://vimeo.com/27543915) [domdocument.load]: failed to open stream: HTTP request failed! HTTP/1.1 404 Not Found

Should the domdocument.load have a value?

DOMDocument::load will return a DOMDocument Object if it succeed.... what do you mean by having a value ?

Can you acces http://vimeo.com/api/oembed.xml?url=http://vimeo.com/27543915 from your browser ?

Yes I see the page and returned XML fine.

Hum so your IP is not blocked... I follow the UA track then....

It's weird how localhost works but the staging site throws the error, gonna try re-installing the ensemble and see if that makes a difference on the server. I'll keep you posted.

Reinstalling won't change anything. I don't think you fully understand what is going on...

The different between localhost makes quite a difference since I can guess that they do not request thing with the same IP.

This is what's happening at the network level

  • Your browsers asks your server (localhost or stage) to save the entry
  • While trying to save the entry, the server (localhost or stage) makes a HTTP request, with its IP to vimeo.
  • This is where we failed. The response return by Vimeo to your server is not valid and your server sends you back an error page.

Unless you can provide some info about the HTTP request between your stage server and vimeo's, I cannot really help on that since I can't reproduce your entry... Sorry

Hi Nitriques, thanks for your reply.. I have installed Fiddler on my local PC and will have a dig around in the next few days.. Have resorted to normal text input field for VIMEO Id for now and upload field for thumbnail. Site goes live Monday so wanted the fallback in place while we look further at the host.

Thanks again.

Hi Nitriques, an update, I started following this twitter account http://twitter.com/#!/vimeoapi and realised the last post was after I was experiencing issues.. I'll check out the saving of entries again tomorrow and hopefully will have it working again. :) fingers crossed.

This is what I was suspecting. I will improve error handling in the future. If you have free time, feel free to fork and pull !