This is really an "interesting" problem:
http://socds.huduser.org/permits/output_monthly_csv.odb?outpref=csv&geoval=state&datatype=monthlyF&varlist=1%232%233&yearlist=2000%232001%232002%232003%232004%232005%232006%232007%232008%232009%232010&statelist=13%2337%2345&msalist=+&cbsalist=+&bppllist=+&cntylist=13033%2313073%2313189%2313245%2337007%2337025%2337071%2337119%2337179%2345001%2345003%2345005%2345007%2345009%2345011%2345013%2345015%2345017%2345019%2345021%2345023%2345025%2345027%2345029%2345031%2345033%2345035%2345037%2345039%2345041%2345043%2345045%2345047%2345049%2345051%2345053%2345055%2345057%2345059%2345061%2345063%2345067%2345069%2345065%2345071%2345073%2345075%2345077%2345079%2345081%2345083%2345085%2345087%2345089%2345091&COUNTYSUM=YES&COUNTYALL=+&COUNTYGRP=+&STATESUM=+&STATEALL=+&METROSUM=+&METROALL=+&METRO=+&CBSA=+&PLACEGRP=+&CSUMNAME=&JSUMNAME=+&geo=state&chron=monthlyF
On Windows you may see older versions of wget give the error message "Result too large" but it means filename too long. In Linux "File name too long". And wget 1.13 --trust-server-names doesn't work with this site's response.. should it?
Well, in theory it should work with "--content-disposition=on", as the webapplication sends a Content-Disposition header with a filename:
---response begin--- HTTP/1.1 200 OK Content-Type: application/vnd.ms-excel Server: Microsoft-IIS/6.0 Content-Disposition: attachment; filename=BuildingPermits.csv; X-Powered-By: ASP.NET Date: Sat, 17 Sep 2011 05:58:06 GMT Connection: close ---response end---
... but wget seems to bail out with the overlong filename *before* it reads the response headers.
Best regards, Jochen Roderburg
