Ask HN: Unknown. Not Unknown or expired link, just Unknown.

10 points by philhippus ↗ HN
When I try to load HN through my http proxy, I get a blank screen with "Unknown." displayed in the top left corner. I've traced this output back to srv.arc and here is the code:

(= unknown-msg* "Unknown." max-age* (table) static-max-age* nil)

(def respond (str op args cooks ip) (w/stdout str (iflet f (srvops* op) (let req (inst 'request 'args args 'cooks cooks 'ip ip) (if (redirector* op) (do (prn rdheader) (prn "Location: " (f str req)) (prn)) (do (prn header) (awhen (max-age* op) (prn "Cache-Control: max-age=" it)) (f str req)))) (let filetype (static-filetype op) (aif (and filetype (file-exists (string staticdir* op))) (do (prn (type-header* filetype)) (awhen static-max-age* (prn "Cache-Control: max-age=" it)) (prn) (w/infile i it (whilet b (readb i) (writeb b str)))) (respond-err str unknown-msg*))))))

I don't read Lisp, let alone Arc but it seems like this code is parsing the http response headers and outputting the error message based on the Cache-Control header value.

Am I warm?

Edit: The URI causing this is news.ycombinator.com

9 comments

[ 3.9 ms ] story [ 31.2 ms ] thread
I have no idea and can't help you, but it may help others if you mention exactly the URL that you are trying to load.
I would guess the problem is with your proxy... or some rare hiccup while pg did some testing.

in any case: what are your request headers?

It's a transparent proxy, so the request headers are whatever is generated by the browser by default. I do inject a script into the returning http stream, but so does my antivirus without issue. Even if I send an empty script file, the error occurs.
we still need your request headers.... the real ones, not the one you think you have
http://i.imgur.com/VhQlE.jpg The link is a screen cap of the GET request and the displayed error message from Chrome.
The request looks wrong. Normally you should see a host header of "news.ycombinator.com" and a URL of "/". I.e., it should read "GET / HTTP/1.1".
Yes. This is a "no such file" error.
The request is not wrong, the server is wrong. Your answer makes sense though...I had a similar issue with Wordpress mangling redirects because it can't handle absolute URI's after GET.

When you change your internet settings on Windows to use a proxy, this is the format to which browsers generate requests.

From RFC 2616 5.1.2 Request-URI http://www.w3.org/Protocols/rfc2616/rfc2616-sec5.html :

'To allow for transition to absoluteURIs in all requests in future versions of HTTP, all HTTP/1.1 servers MUST accept the absoluteURI form in requests, even though HTTP/1.1 clients will only generate them in requests to proxies.'

My proxy shouldn't have to alter the request, according to the standard.

(comment deleted)