Stack Apps is a question and answer site for apps, scripts, and development with the Stack Exchange API. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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<��


share|improve this question

migrated from Apr 1 '11 at 10:33

This question came from our discussion, support, and feature requests site for professional and enthusiast programmers.

up vote 4 down vote accepted

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.

share|improve this answer
But I guess it's hard to make error pages return the correct encoding headers too? (Just like the 200 OK response does.) – Arjan Apr 1 '11 at 19:14
@Arjan - most error pages do, this particular one was well ahead of our code in the pipeline though. – Kevin Montrose Apr 1 '11 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 Apr 1 '11 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 \\&intitle=%3Cdiv%3E
    > 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:
    > 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
    < [...]
share|improve this answer

You must log in to answer this question.

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