The Stack Overflow API query


returns what appears to be binary data:

���I�%&/m�{J�J��t��$ؐ@�������iG#)�*��eVe]f@�흼��{����{����;�N'���?\fdl��J�ɞ!���?~|?"��Ey�')=��y6�����h����z��<=���~|W>�Z5�u�A:�f��/>����y�(��G�d^ϲe��!z���Ѳ�Y)5��G��A�8�VeU?������/I=����Yd�E��n�գt����/�q� �IU�n �ۻ�/No�������N�|� ��&�}�0��euU���?_O�Y��T˦*s�3�0_�/� �ۼV�@ʄJ��TH�����Y>���-���tY-���e^7�U���ŋ:�[���+�'U�V�G����]�ݻU��e��F�v{^/gy]�{�#����.���u��su�S��]���Uq�?��'賏��E�d�� B����w�^�5�[�*-���w?N�W���2����:�*f���ݝ��=�,|�+h~�%�{��.���0�;J]�-�������E��l���q]d�(�vN����(�<_�����z�:[6ۯ��u�գ��_M^�id����i�L�b%3�����x�fn��Ll5%�����v�� �f������m�nh���&o�by��D��F�@��/� @��6+�&����~��5A��-�,�+B��U�����9wE�5}�5$w��aS���(�WW�b���'�uuECh�z�\����Y��K�tN�8�Ҍ�����S�#P1}S�����7H"F�ʧ�y1�!.���.�ie��7 +������FID����Y�KR Ly���^��i�]kROK��E��=��'�i�7��dMA��:Ĺº���:|cy|���%���n� �i�|��!"Q�yA�m���,����Z�Y n��fKH���r�(g�����c�Oq~�w��B�Y~����U.<�c����?~���S��'v]UŒ�6��W��������Uܗ��Zg�3O�lq-@�1���_�ybq�=�O�����?���8<��


  • I think it is a gzipped api response Commented Apr 7, 2019 at 8:22

2 Answers 2


ASP.NET was freaking out about the < in your search term.

Fixed it*.

More generally, the API always returns compressed content; so everything is "binary," this case just showed it more obviously due to the unusual error.

*It's worth noting that the actual < and > are not indexed by our Lucene search provider, so you can't actually search for <div>: you'll be searching for div instead. It doesn't explode anymore if you try though.

  • 1
    But I guess it's hard to make error pages return the correct encoding headers too? (Just like the 200 OK response does.)
    – Arjan
    Commented Apr 1, 2011 at 19:14
  • @Arjan - most error pages do, this particular one was well ahead of our code in the pipeline though. Commented Apr 1, 2011 at 19:20
  • No worries, if a 500 error ever shows again, the search for the binary data will point folks to this very question! ;-) (Well, at least the Google search does!)
    – Arjan
    Commented Apr 1, 2011 at 19:39

I guess there are two problems:

  1. Leaving out the opening %3C does show (different?) results, so why does that opening bracket have this effect?

  2. With the opening angle bracket, this yields an ASP error page, but gzipped. However, the response headers don't say it's compressed, leaving the browser (or whatever application is handling this) oblivious about it:

    curl -o output.txt -v --compressed \
    > GET /1.1/search?tagged=javascript&intitle=%3Cdiv%3E HTTP/1.1
    > User-Agent: curl/7.19.7 (universal-apple-darwin10.0) libcurl/7.19.7 [...]
    > Host: api.stackoverflow.com
    > Accept: */*
    > Accept-Encoding: deflate, gzip
    < HTTP/1.1 500 Internal Server Error
    < Cache-Control: private
    < Content-Type: text/html; charset=utf-8
    < X-AspNet-Version: 4.0.30319
    < Date: Fri, 01 Apr 2011 09:22:43 GMT
    < Content-Length: 1194

    However, manually uncompressing does result in an "Server Error in '/' Application" error page. Also, a normal response does include the proper header:

    < HTTP/1.1 200 OK
    < Cache-Control: private
    < Content-Type: application/json; charset=utf-8
    < Content-Encoding: gzip
    < [...]

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .