Ask HN: Bug in Hacker News ResponseStatusLine | Hacker News Reader

Ask HN: Bug in Hacker News ResponseStatusLine

3 pointspj6 comments

Could not load feed - The server committed a protocol violation. Section=ResponseStatusLine

Looks like the web server isn't sending back enough headers:

  HTTP/1.x 200 OK
  Content-Type: text/html; charset=utf-8
  Connection: close

Where are Content-Length, Last-Modified, etc?

Should be more detailed like this one from google.com:

  HTTP/1.x 200 OK
  Content-Type: image/x-icon
  Last-Modified: Fri, 09 Jan 2009 16:35:02 GMT
  Date: Fri, 05 Jun 2009 17:40:31 GMT
  Expires: Sat, 05 Jun 2010 17:40:31 GMT
  Cache-Control: public, max-age=31536000
  Server: gws
  Content-Length: 1150
  Age: 1

Or this one:

  HTTP/1.x 200 OK
  Cache-Control: private, max-age=0
  Date: Fri, 05 Jun 2009 17:40:31 GMT
  Expires: -1
  Content-Type: text/html; charset=UTF-8
  Content-Encoding: gzip
  Server: gws
  Content-Length: 3279

View on HN

Sounds like you have a very picky feed reader. Which one is it? And what specifically is it complaining about?

Does anyone know if the http protocol actually mandates more header lines than we're supplying?

Hard to say without the request but he may be doing persistent http connection (keep-alive) in which case content-length is required.

Hmm, it is complaining about the status line (the first one). I think it is choking on the HTTP 1.0 response with a Connection header. That header was added in HTTP 1.1, but lots of people use it with HTTP 1.0 and pretty much everyone supports it. (edit: by which I mean they ignore it, because connection: close is the default behavior in HTTP 1.0)

That said, you should add an ETag to the response. Hacker News changes often enough that timed expiration won't help, but ETags might get you a lot of 304 Not Modified responses.

So if I just change the current header to say HTTP 1.1 am I done, or does that require additional changes?

It doesn't require additional changes. I'm not sure it will fix the .NET client library's paranoia though--I was only guessing.

I'm using the .net HTTP libraries. Not a specific feed reader, rather I'm pulling in the XML and parsing it out.

Here's a thread from somewhere else about the issue. http://channel9.msdn.com/forums/TechOff/257803-HttpWebReques...

When I added the web.config setting, as explained in the article, it works:

  <system.net>
    <settings>
      <httpWebRequest useUnsafeHeaderParsing="true" />
    </settings>
  </system.net>

I think I remember a similar issue from the past related to a missing content-length header.

Reply on news.ycombinator.com