Things missing from Hack

[Michael Snoyman]

I'm going through the list of CGI environment variables to see what needs translation to HTTP header names. Some variables, like SERVER_SOFTWARE, will stay the same. Some, like QUERY_STRING, are already picked up by Hack, and thus I'm going to leave them alone. (I considered removing them from the http variable list, but I think it doesn't hurt to leave it.)

REMOTE_HOST, however, is neither an HTTP variable or included in Hack. This seems like something we should add; I know I'm going to want to do logging as Middleware, and I would like the logging to work for all handlers, not just the CGI/FastCGI ones.

Also, since the following are frequently enough used, perhaps we should consider including them as fields in Env? They are:
Content-type
Content-length
Cookie

Finally, should we try to standardize capitalization somehow? I'm going to follow the headers list on Wikipedia (http://en.wikipedia.org/wiki/List_of_HTTP_headers) for now, but I'm not sure if all browsers agree to send Content-Type instead of Content-type. We *could* force everything to be lowercase, or even provide an http lookup function that uses a case-insensitive match.

Michael

[Jinjing Wang]

> REMOTE_HOST, however, is neither an HTTP variable or included in Hack. This
> seems like something we should add; I know I'm going to want to do logging
> as Middleware, and I would like the logging to work for all handlers, not
> just the CGI/FastCGI ones.

I'm not sure, generally speaking, If it's handler specific, then
probably it won't go into Env, since other handler won't be able to
put information into it, e.g. happstack-server has no knowledge of
remote_host.

If it's commonly used then it might go into http, otherwise hackHeader
/ aka custom.

> Also, since the following are frequently enough used, perhaps we should
> consider including them as fields in Env? They are:
> Content-type
> Content-length
> Cookie

I prefer them to stay inside http headers, since getting / setting
header values can be achieved by helper method, while leaving the
interface small. Besides they are just standard http
headers , moving them to Env will be a bit confusing.

> Finally, should we try to standardize capitalization somehow? I'm going to
> follow the headers list on Wikipedia
> (http://en.wikipedia.org/wiki/List_of_HTTP_headers) for now, but I'm not
> sure if all browsers agree to send Content-Type instead of Content-type. We
> *could* force everything to be lowercase, or even provide an http lookup
> function that uses a case-insensitive match.

Converting non-standard header names to standard names inside a
handler is fare enough.

Cheers,

--
jinjing

[Michael Snoyman]

On Mon, Jun 1, 2009 at 9:57 PM, Jinjing Wang <nfji...@gmail.com> wrote:

> REMOTE_HOST, however, is neither an HTTP variable or included in Hack. This
> seems like something we should add; I know I'm going to want to do logging
> as Middleware, and I would like the logging to work for all handlers, not
> just the CGI/FastCGI ones.

I'm not sure, generally speaking, If it's handler specific, then
probably it won't go into Env, since other handler won't be able to
put information into it, e.g. happstack-server has no knowledge of
remote_host.

If it's commonly used then it might go into http, otherwise hackHeader
/ aka custom.

Don't you think that applications might like to know the hostname/IP address of the client? The only reason Happstack doesn't provide it is that it's not necessary in a regular server environment.

> Also, since the following are frequently enough used, perhaps we should
> consider including them as fields in Env? They are:
> Content-type
> Content-length
> Cookie

I prefer them to stay inside http headers, since getting / setting
header values can be achieved by helper method, while leaving the
interface small. Besides they are just standard http
headers               , moving them to Env will be a bit confusing.

Alright, I'll buy that.
 

> Finally, should we try to standardize capitalization somehow? I'm going to
> follow the headers list on Wikipedia
> (http://en.wikipedia.org/wiki/List_of_HTTP_headers) for now, but I'm not
> sure if all browsers agree to send Content-Type instead of Content-type. We
> *could* force everything to be lowercase, or even provide an http lookup
> function that uses a case-insensitive match.

Converting non-standard header names to standard names inside a
handler is fare enough.

Code for that is already done, just look on Github ;).

Michael

[Jinjing Wang]

If remote_host is to be added then maybe so is remote_addr and
remote_user? Since they can all be used in common-logger? I still
think it makes the interface a little bloated, and these maybe kinda
of attributes are ideal to be placed under hackHeaders, but please
point to me if wronged.

--
jinjing

[Michael Snoyman]

You can put it under hackHeaders if you want, but the point is that we need some kind of standard of where it should be. Right now, there's no way to know how to find the clients IP address/host.

Michael