View Single Post
  #10  
Old 07.06.2011, 19:21
bboard
Guest
 
Posts: n/a
Default

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:

Quote:
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.
[...]
Code:
Location       = "Location" ":" absoluteURI

I will keep you posted about this issue.
Reply With Quote