jumblrClient.blogAvatar() gets wrong response code? #94
Comments
|
@BryanRansil I just gave it a test and do receive a Input User user = client.user();
Blog blog = user.getBlogs().get(0);
System.out.println("Blog.avatar(): " + blog.avatar());
System.out.println("JumblrClient.blogAvatar(): " + client.blogAvatar(blog.getName()));Output I also checked the request directly in curl. Curl (abridged) $ curl -v https://api.tumblr.com/v2/blog/staff.tumblr.com/avatar
> GET /v2/blog/staff.tumblr.com/avatar HTTP/1.1
< HTTP/1.1 301 Moved Permanently
{"meta":{"status":301,"msg":"Moved Permanently"},"response":{"avatar_url":"https:\/\/66.media.tumblr.com\/avatar_db722a134cda_64.png"}}Closing this issue unless @BryanRansil can provide some code to reproduce. |
|
@ceyko Thanks for the quick response! I tried the code you provided on two phones, one which is Ice Cream Sandwich (where it worked) and one which is an LG3 on Marshmellow (where it failed). Hopefully I can test my current theory that it's a Marshmellow issue by downgrading the Marshmellow phone and seeing if it still works but won't be getting to it tonight. Here's the error that appears when I try on the LG3: And here's what I get when I print the error message and stacktrace: Thanks for your time! |
|
@BryanRansil It looks like it is still following the redirect. We do set it to not follow redirects immediately before making the request, and HttpURLConnection#setFollowRedirects() has existed since SDK v1, so I'm not sure if downgrading will fix it. However, we do use the static version of this setter, so it affects and is affected by anything else calling it. Perhaps you have another thread which is calling In light of this, I'm reopening this issue, since it seems like we don't handle multithreading very well. We should replace the usage of |
ceyko
added a commit
that referenced
this issue
May 3, 2016
When setting no-follow-redirects for an avatar request, do so only for this one request. Previously, it was set globally for all requests, then set back to its initial state after the request completed. This should prevent multithreading issues where numerous threads are attempting to alter the state of HttpURLConnection#setFollowRedirects(). Fixes #94
ceyko
added a commit
that referenced
this issue
May 3, 2016
When setting no-follow-redirects for RequestBuilder#getRedirectUrl() (e.g., avatar requests), do so only for this one request. Previously, it was set globally for all requests, then set back to its initial state after the request completed. This should prevent multithreading issues where numerous threads are attempting to alter the global state of HttpURLConnection#setFollowRedirects(). Fixes #94
ceyko
added a commit
that referenced
this issue
May 3, 2016
When setting no-follow-redirects for RequestBuilder#getRedirectUrl() (e.g., avatar requests), do so only for this one request. Previously, it was set globally for all requests, then set back to its initial state after the request completed. This should prevent multithreading issues where numerous threads are attempting to alter the global state of HttpURLConnection#setFollowRedirects(). Fixes #94
|
Thanks! I've subscribed to the issue so I'll see how that goes. |
BryanRansil
added a commit
to BryanRansil/SimpleTumblr
that referenced
this issue
Sep 7, 2016
Using the jumblr api calls on an LG3 Phone with Marshmellow caused a crash, specifically when attempting to get the avatar link. This was mentioned in tumblr/jumblr#94, but the crash was not reproduciable by the developers. After several more attempts on my side to figure out what I was doing differently I resorted to using the deeper level API to get the avatar. After getting that to work, I refactored the AuthorView with this new capability in mind.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Firstly thanks to everyone who contributed to this api, it's fun to play with!
I'm trying to get the blog avatar right now, and that goes to requestBuilder.getRedirectUrl(). I'm getting a response code of 200 (HTTP_OK) as opposed to 301 (HTTP_MOVED_PERMANENTLY). It seems HTTP_OK the response doesn't have the Location header, so it makes sense to not try to use the response. However I don't know if there's anything I can do on my side to deal with this (like something I've just not setup correctly) or if I can get help from anyone for how to debug this further. Any help would be appreciated!
The text was updated successfully, but these errors were encountered: