Really stupid thing with c# WebReqest.DownloadString
-
Working code:
private static WebClient hitboxWebClient = new WebClient();
var data = hitboxWebClient.DownloadString(new Uri(@"http://www.hitbox.tv/api/chat/servers"));
Result:
data = "[{\"server_id\":\"137\",\"server_type\":\"chat\",\"server_name\":\"\",\"server_host_name\":\"ip-10-196-73-69\",\"server_location\":\"\",\"server_ip\":\"23.20.66.156\",\"server_internal_ip\":\"\",\"server_load\":\"0.0000\",\"server_enabled\":\"1\",\"server_...
Issue with the above: These are apparently the old servers, so I needed to use the new ones
var data = hitboxWebClient.DownloadString(new Uri(@"http://www.hitbox.tv/api/chat/servers?redis=true"));
Result:
"‹\b\0\0\0\0\0\0•ÍÍ\nƒ0àwɹ#ÙM61¾J\t’CVñZúîƳôð0ìÇ<¿jIóžæî5©F¥ž!5ƒ€´¯úq˜¶5ª8ÄÏøŽÇruê÷¸Ëü¾‚)‚y’µ‰—Rr.Ç ØâQ#‚ePƒ<j\rvÿ]{\a‹š\\Z\0\0"
This reeks of an encoding issue, but I'm at a loss as to what's actually happening. I have tried several variations of utf-8, unicode, ascii, etc, and all seem to be equally wrong.
Anybody able to point and laugh at me, say i'm doing it wrong, and point out wtf is actually wrong? I'm just trying to get the literal string data from the page. No formatting in any way.
Of note, this request does return the correct information for like ONE of the 7 or so servers available, which is part of the reason why I think it's my request/response getting garbled.
-
I personally like how the differentiation between new and old servers is the ?redis=true argument. So much for paths.
Either:
- WebClient is shitting itself over the MimeType.
- The ?redis=true path is returning gziped content regardless of the http headers
-
Now there's a possibility, aws could certainly be gzipping the response.
-
WebClient is shitting itself over the MimeType.
The different servers seem to be responding with different mimetypes.
-
My guess is the text/html one is causing your webclient to shit itself?
I get that one about 1 in 4 attempts.ONE of the 7 or so servers available
So I guess it's probably more like 1 in 7 attempts that i get the HTML one then :)
-
I just tested the gzip theory. The server always returns gziped content even if I tell it accept encoding none.
-
Oh jeeze, is there a simple way to test for that or am I going to have to go Frankenstein?
-
Bingo! Found the problem.
the text/html is NEVER gzipped.
application/json is getting gzipped regardless of your client headers.
-
Oh jeeze, is there a simple way to test for that or am I going to have to go Frankenstein?
You can't change their side to always return application/json instead of half and half? Because half and half is a whole of broken.
You should be able to read the content type in the response and deal with them separately though.
-
The HTML is fine. It's the json mime type being force encoded.
-
I don't control hitbox.tv, I'll drop it in their suggestion box, but you know where companies usually stick that.
-
All you need is the first answer and you are done.
-
Will pull this in a moment when I'm back to my computer.
-
bizarre, I got the JSON one more often than the HTML one. Guess it was just luck of the draw then.
Either way, @matches will have to read the content type out of the header and deal with each one separately.
-
The webclient "hack" I linked just turns on automatic decompression on the HttpWebRequest internal to the class. That will take care of it without mime type nonsense.
Blame microsoft for making a webclient without gzip by default.
-
Cool. It's basically doing the same thing internally then, checking whether the request is gzipped and decompressing if necessary?
And blame the webserver for responding with GZIP despite the client very likely begging it not to do so.
-
Hey, we get both a client and server wtf
-
both a client and server wtf
WIN WIN.
So we can haz 1 cookie each. My cookie can be smaller since I only got halfway the answer.anyway, now it is diablo time.
-
"[{\"server_ip\":\"ec2-54-235-51-79.compute-1.amazonaws.com\"},{\"server_ip\":\"ec2-50-17-80-26.compute-1.amazonaws.com\"},{\"server_ip\":\"ec2-54-166-163-94.compute-1.amazonaws.com\"},{\"server_ip\":\"ec2-107-22-10-93.compute-1.amazonaws.com\"},{\"server_ip\":\"ec2-54-204-156-212.compute-1.amazonaws.com\"},{\"server_ip\":\"ec2-54-82-245-107.compute-1.amazonaws.com\"}]"
+139035839572027830 looks like it's working after several attempts.
It is times like these that I regret the double like bug has been fixed. Maybe we should ask for it as a site wide option?
-
Dear Jeff,
You know how we make fun of you for your bugs?
Well we want a bug back.
It was fun.
Regards,
TDWTF Users
-
-
well that will die fast.
-
Maybe, but @delfinom gets another +1, because he saved me a lot of time fucking with this stupid bug.
-
I love the fact that the first reply is the stereotypical FOSS response.
-
well that will die fast.
Actually, I think he took it pretty well. Probably built up some goodwill.
-
Actually, I think he took it pretty well. Probably built up some goodwill.
I think that just means the suggestion was so inane that he took it seriously.
Or maybe it was serious. I don't even anymore.They deleted MY "keep this bug in place, I like it" topic that I started about the ability to use unicode to fake mentions @ ┴╩▲darkmatter allowing actual profiles to link thing. It was deleted with no response within about 10 minutes. Maybe it's my profile pic on meta.d (which was the Jeff as clippy img, now it's burns though).
-
You know you could just look for the Content-Encoding header on return, right? In your case where it's gzipped, it's actually telling you that. And when you had the screenshot of it not being gzipped, no Content-Encoding header.
-
The goal is to fix bugs, then replace them with the proper feature equivalent. Sure, it's more work, but it's the right way to do it.
-
I don't work with interwebs UX often, I am usually an insolated SQL/C# programmer in enterprise environment. I'm branching out and making something fun.
-
HTTP has its faults but it's pretty good at telling you what's going on when done properly