json-head. I’ve deployed another App Engine mini-app, which provides a JSON-P API for running HEAD requests against an arbitrary URL (useful for checking things like Content-Length and Content-Type headers and whether a URL returns 200). App Engine’s urlfetch limitations mean it can only deal with port 80 and 443 requests.
Sign in with 
OpenID
json-head doesn't like itself: http://is.gd/17B6 ; other than that, coolio! I wonder if application/javascript is the best content-type to be sending here. Not *quite* appropriate, I think. Except for the callback version, of course.
I believe urlfetch supports 80 (http) and 443 (https).
http://code.google.com/appengine/docs/urlfetch/ove rview.html
Niall Kennedy - 29th July 2008 17:43 - #
Patrick: I deliberately used the wrong content-type (application/json is registered now) because I get really annoyed when my browser downloads an API response instead of displaying it directly - I like my JSON APIs to be mostly self documenting.
Niall: I posted a correction.
Great! So many convenient coinsidences today : )
Today I created yet another userscript which resolves links shortened by one of russian link-shortening servers to their full lengths. Unfortunately userscripts in opera can't make requests to other domains, thus I created small php proxy for myself. I didn't release it publicly because I'm not sure my hosting can handle lots of requests. I had an idea of using App Engine for this, but I'm still in queue. And now you create json-head!
Unfortunately (again) this server b23.ru doesn't understand HEAD requests for these redirects : (
Maybe you could add possibility to use GET, but read only headers from other server? Thus it won't consume much bandwidth too.
Might consider content negotiation - if the Accept: includes something close to application/json (I've used text/json in the past as well), then return what it asked for. Otherwise, return text/plain.
I definitely feel your pain w/r/t having the "download" function taking over when you 'surf' to some JSON, but it seems wrong for the right answer to be "what it takes to make the debug story work in a browser". Penalizes people who want to do the 'right' thing.
What are the error codes?
I can see that
ApplicationError: 1 = no or wrong url
ApplicationError: 2 = non existant domain
ApplicationError: 3 = ? (i've just encountered one - network timeout?)
Marin - 14th August 2008 19:03 - #
I'm curious--why did you implement this as a service instead of just a Javascript function to directly XHR and parse the headers?
Thanks so much for this! I'm writing a new site for my podcast in django. This is the best solution I found for being able to figure out the content-lengths for all of the old episodes.
> useful for checking things like Content-Length
> and Content-Type headers and whether a URL
> returns 200).
This is exactly what I'm using this service for on my new blog: http://jazz.appspot.com
Thanks for making this available :)
Karim - 27th November 2008 20:12 - #