[Solved] uploaded.to "Plugin Error - out of date"

Since 30 minutes ago I am getting the "Plugin Error - out of date"-Error.

uploaded.to
Premium Account
Enough Traffic

I restarted JDownloader, my PC and the Router.

**External links are only visible to Support Staff**DL-Container


Greetings from Germany

[Jiaz]

uploaded issues, i cant download myself

These errors are pretty common nowadays on uploaded.to.

Instead of throwing a plugin defect error, it would be better handle this error gracefully by marking the file as temporary down (like other plugins already do), and continue with the download of this files after a waittime.

**External links are only visible to Support Staff****External links are only visible to Support Staff**
**External links are only visible to Support Staff****External links are only visible to Support Staff**

(these 2 files are 'temporary not reachable' since weeks, but I've seen others where this message disappeared after some minutes).

You're right. As far as I can see the site doesn't provide any indication of an error. It just doesn't allow you to download the file.

This should be seen as a temporary error instead of a plug-in error.

[Jiaz]

wait for plugin update

Despite the update for Bug #3317 today, the error is still not handled correctly neither for free user (404 which results in a permanent 'file not found' marking in JD), nor for premium users (still results in a plugin defect).

I assume ul.to changed their site again after #3317 was fixed. You can just use the urls above to test.


The issue with these 2 files when downloading with a premium account is that instead of doing a 'POST /dl/<downloadtoken> HTTP/1.1', I can see JD doing a 'GET /file/<fileid>/dl/<downloadtoken> HTTP/1.1'. In the browser, after the 'POST /dl/downloadtoken HTTP/1.1', I can see the following part in the html content:

	<div style="text-align:center;padding:30px 0px;">
		<p style="margin:10px 0px;">
			Aus technischen Gründen ist ein Download momentan nicht möglich.		</p>
		<p style="margin:10px 0px;">
			In <b id="tout">16</b> Sekunden wird ein erneuter Versuch gestartet&hellip;
		</p>
			</div>

seems like this error message is always in german btw.

[Jiaz]

3317 has nothing to to with uploaded!

please provide a complete log

the both example links above are offline

Indeed, 3317 doesn't matter, sorry.

The files above are not offline, they are temporary not reachable. If you open both of them in your browser, you will see the message I mentioned (Aus technischen Gründen ist ein Download momentan nicht möglich.)

What I am asking is that you detect this message, but because JD is making wrong request ('wrong' in terms of 'not equal to a webbrowser'), this message will not even come out on the wire.

Please see my last post for wrong and correct request (there is a rather bogus Location Redirection request, which probably violates the rfcs, but it works in the browser).



premium account log:
http://jdownloader.net:8081/pastebin/41726

free user log:
http://jdownloader.net:8081/pastebin/41727

[Jiaz]

i get
Page not found
Error: 404

Please check the URL for typing errors, respectively contact us in case of a technical failure.

jd works correct as we use their api and the request is a get request
**External links are only visible to Support Staff****External links are only visible to Support Staff**

post and get are no difference here. its a known uploaded server issue and the files are offline

When i try to download in IE as a free user, after the waittime & captcha I will get a 404 (same behavior as in JD).

When I download in FF or Opera as a free user, I do see this german error message, after the waittime & captcha (behavior probably expected by the uploaded.to devs).

Even if you open it in IE, you will see that the file is not down (when looking at the first page). Also the API answer confirms that the file is up.

Both files are up and only temporary down. Why should JD otherwise correctly detect the file size and the online status (=UP) when querying the API?


Yes, '**External links are only visible to Support Staff** is the correct URL, but thats not the point. '**External links are only visible to Support Staff** does not contain the download token, it is the api request to get a new downloadtoken. The difference between the browser and the JD-behavior is when using the download token on this temporary down links:

FF/opera requests go to /dl/<downloadtoken> (error message)
JD requests go to /file/<fileid>/dl/<downloadtoken> (404)
IE requests go to /file/dl/<downloadtoken> (404)

NOTE: this problem only appears on those strange temporary down links.



While writing this post (and seeing the JD behaves similar to IE, but not like FF and Opera), I changed my opinion:

The behavior of uploaded.to is so hardly broken, that I will rather contact them to fix their RFC Violation, so we have a consistent behavior on all browser and we will automatically fix this issue:

Originally Posted by **External links are only visible to Support Staff**RFC2615, section 14,30

The Location response-header field is used to redirect the recipient to a location other than the Request-URI for completion of the request or identification of a new resource.
[...]
The field value consists of a single absolute URI.
[...]

Location       = "Location" ":" absoluteURI

I will keep you posted about this issue.

[Jiaz]

because the api is outdated many hosters suffer from this, not only uploaded

they have a lot more non rfc conform stuff and again they are not the only ones