Skip to main content
Note on the regular response
Source Link
Arjan
  • 188
  • 5

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 \
     http://api.stackoverflow.com/1.1/search?tagged=javascript\&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: 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""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
     < [...]
    

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 \
     http://api.stackoverflow.com/1.1/search?tagged=javascript\&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: 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.

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 \
     http://api.stackoverflow.com/1.1/search?tagged=javascript\&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: 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
     < [...]
    
Source Link
Arjan
  • 188
  • 5

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 \
     http://api.stackoverflow.com/1.1/search?tagged=javascript\&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: 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.