For APIs, it seems more and more data is making its way into the HTTP headers.  Recently, whilst adding a `Link` header, for paging data, into the HTTP response, I realized that my browser code couldn't see it.  Who was the culprit?  CORS, of course.



## Headers in Browser 

It was just another day, and I was developing in my browser of choice, Chrome, known, in part, for its unequaled developer tools.  The `Link` header that I had added onto my HTTP responses for my API were viewable from the Network tab.  It looked good.  The browser could see it, curl could even see it.

In the browser client code, I was using `superagent`, but the code failed to see it.  I'd run:
  
```js
var request = require('superagent')
request.get('myApi').end(function (err, res) {
  res.xhr.getResponseHeader('Link') // nothing
  res.headers.link // nothing
})
```

And the header was not coming through.  I ran the same command in the console, `res.xhr.getResponseHeader('Link')`, and got the error response:

```
Refused to get unsafe header ‘Link’
```

These are a classic CORS symptoms.  

## CORS Spec

Well, a few great [google results](http://blog.import.io/tech-blog/exposing-headers-over-cors-with-access-control-expose-headers) later, I ended up at the [CORS spec](http://www.w3.org/TR/cors/#simple-response-header), which drones on that only simple headers are allowable in CORS requests by default.  These headers include:

- Cache-Control
- Content-Language
- Content-Type
- Expires
- Last-Modified
- Pragma

`Link` is definitely not on that list.  So, how to add it?

## Access-Control-Expose-Headers in rack-cors

Like the other CORS headers, the `Access-Control-` prefix is present.  The one you're looking for is [`Access-Control-Expose-Headers`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS).  It is a comma-separated list of header names. You can add this header manually to your response, or depending on the library you're using, it might be added differently.

I was using `rack-cors`.  Thus, my addition ended up looking something like this in `config/application.rb`:

```ruby
# ...
config.middleware.use Rack::Cors do
  allow do
    origins '*'
    resource '*', :headers => :any, :methods => [:get, :post, :put, :delete, :options], :expose => ['Link']
  end
end
```

Can you see that the `expose` key was the key for me?  Once that was added, the browser let the client code read the link, and all was safe and well.  

## Bonus:

As a bonus, here's a great client library for consuming a [GitHub API-style](https://developer.github.com/v3/#link-header) `Link` header, called [parse-link-header](https://www.npmjs.org/package/parse-link-header)

If you don't see your HTTP response header in the browser, check your CORS policy.  It's likely the culprit.

Expose HTTP Headers in CORS

Spring is a great addition to your Java stack.  It helps you access the request for inside your Spring beans easily.  Maybe I'm doing it wrong, but reading the request body seems blasted verbose after that.  It takes a surprising amount of code.  



## Access the Request

Spring's bread and butter, of course, is inversion of control.  So, to get to the request object itself is no big deal.  Just inject it (canonical packages shown for… fun, mostly):

```java
@javax.inject.Inject
javax.servlet.http.HttpServletRequest req;
```

And now for the pile of non-abstracted code.

## Parse the Body

Number one, the body is accessed from the [`HttpServletRequest`](http://docs.oracle.com/javaee/6/api/javax/servlet/http/HttpServletRequest.html) object it a place that wasn't obvious to me: `request.getReader()`.  Heads up, we've got a BufferedReader here.  Hey, at least we don't get a stream that we have to wrap in more than one reader!

```java
private String getBody() {
  String body = "";
  if (req.getMethod().equals("POST") )
  {
    StringBuilder sb = new StringBuilder();
    BufferedReader bufferedReader = null;

    try {
      bufferedReader =  req.getReader();
      char[] charBuffer = new char[128];
      int bytesRead;
      while ((bytesRead = bufferedReader.read(charBuffer)) != -1) {
        sb.append(charBuffer, 0, bytesRead);
      }
    } catch (IOException ex) {
      // swallow silently -- can't get body, won't
    } finally {
      if (bufferedReader != null) {
        try {
          bufferedReader.close();
        } catch (IOException ex) {
          // swallow silently -- can't get body, won't
        }
      }
    }
    body = sb.toString();
  }
  return body;
}
```
    
The code.  There is to much.  Let me sum up.  There's only going to be a body if you are doing a post.  Otherwise, don't worry about it.  If there is data, pull it into a string.  Everything else is for (not) handling errors.

There's a bit there.  It's not the worst.  But after getting used to [Express' bodyParser](http://expressjs.com/api.html#req.body), it was hard to see this.

Want to read the body of a request within a Spring bean?  It takes a surprising amount of code.

Read Request Body in Spring Bean

Don't you hate developing a blasted simple webpage that does some asynchronous requests that gets you into cross-origin policy trouble.  If you just read a `.html` file off the file system, this will bite you.  But, it's easy to get around.  Just host your .html file on a simple http server.  And it's easy to make that happen.  Here's one way.



## Attacked by Snakes

First, Verify you have python installed:

```bash
> python --version
Python 2.7.3
```

##'Tis a Gift to Be Simple

Then navigate to the directory that you'd like to serve up and type:

```bash
python -m SimpleHTTPServer 5000
```

Where "5000" is the port you'd like to serve it on.  (Defaults to 80.)  Then point your browser to:

    http://localhost:5000

And rock your local dev.

Don't you hate developing a blasted simple webpage that does some asynchronous requests that gets you into cross-origin policy trouble.  If you just read a

Serve a Directory

If you've created an internationalized website lately, you've probably implemented some sort of language chooser widget in your site ui to allow your users to indicate which language they would like to see content displayed in.  What I often forget is that the user may have already made this indication previous to visiting your site, and you might be like to think about respecting their previously indicated preference.



Within the browser, a user can store their preferred language.  The w3c has a [nice browser list](http://www.w3.org/International/questions/qa-lang-priorities#changing) to give some terse instructions on how to set your language in your browser.

Your app might read the browser preference differently, but at least one component is consistent.  Your browser is going to pass an [HTTP header](http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html) called "Accept-Language" to your app.  In a recent app, I read this using XQuery:

```
xdmp:get-request-header("Accept-Language")
```
That's going to return a string something like this one, which is mine:

```
en-US,en;q=0.8
```

This is a comma-delimited list of 2-letter [language codes <http://en.wikipedia.org/wiki/List_of_ISO_639-1_codes>`_ and 2-letter `locale codes](http://en.wikipedia.org/wiki/ISO_3166-1_alpha-2), informally "language-locale".

The "q=#" describes the quality of the language.  The higher, the quality, the more preferred.  Notice that in my header, "en-US", American English, does not have a "q=" attribute.  The lack of "q=" indicates a default, actually the highest preference, of 1.0.

There's also a Content-Language header, that I suppose you could use if you were making a differentiation for what language the actual content was using compared to the site chrome.  But, as far as I can tell, this is used less.  Even less by myself.  (Never.)

Here's a full XQuery implementation for MarkLogic that will read the header and parse out the preferred language.  In my implementation, I don't care about the locale, so I'm paying attention only to the language code.  The regex used is an adjustment of [this original php regex](http://www.thefutureoftheweb.com/blog/use-accept-language-header):

```
xquery version "1.0-ml";

declare option xdmp:mapping "false";

declare function local:get-browser-lang() as xs:string? {
  let $header := xdmp:get-request-header("Accept-Language")
  return if (fn:exists($header)) then
    local:get-top-hit-lang($header)
  else
    ()
};

declare private function local:get-top-hit-lang($header as xs:string) as xs:string? {
  let $langs :=
    for $entry in fn:tokenize(local:parse-header($header), ",")
    let $data := fn:tokenize($entry, "q=")
    let $quality := $data[2]
    order by
      if (fn:exists($quality) and fn:string-length($quality) gt 0) then
        xs:float($quality)
      else
        xs:float(1.0)
      descending
    return $data[1]
  return $langs[1]
};

declare private function local:parse-header($header as xs:string) as xs:string {
  let $regex := "(([a-z]{1,8})(-[a-z]{1,8})?)\s*(;\s*q\s*=\s*(1|0\.[0-9]+))?"
  let $flags := "i"
  let $format := "$2q=$5"
  return fn:replace(fn:lower-case($header), $regex, $format)
};

local:get-browser-lang()
```

This implementation just takes the top language, no matter what.  You might want to check to see if your site actually supports the language before picking from the browser preference.  While you're looping through the list of acceptable languages in get-top-hit-lang(), you could add a where clause to check for support.

Do you find that the sites you visit respect this header?

Update
---------

Here's an updated version of the code that respects secondary language selections as well (not just first choice):

```
xquery version "1.0-ml";

declare option xdmp:mapping "false";

declare function local:get-browser-lang() as xs:string? {
  let $header := xdmp:get-request-header("Accept-Language")
  return if (fn:exists($header)) then
    local:get-top-supported-lang(local:get-browser-langs($header), ("en", "es", "it"))
  else
    ()
};

declare function local:get-top-supported-lang($ordered-langs as xs:string*, $translations as xs:string*) as xs:string? {
  if (fn:empty($ordered-langs)) then
    ()
  else
    let $lang := $ordered-langs[1]
    return if ($lang = $translations) then
      $lang
    else
      local:get-top-supported-lang(fn:subsequence($ordered-langs, 2), $translations)
};

declare private function local:get-browser-langs($header as xs:string) as xs:string* {
  let $langs :=
    for $entry in fn:tokenize(local:parse-header($header), ",")
    let $data := fn:tokenize($entry, "q=")
    let $quality := $data[2]
    order by
      if (fn:exists($quality) and fn:string-length($quality) gt 0) then
  xs:float($quality)
      else
  xs:float(1.0)
      descending
    return $data[1]
  return $langs
};

declare private function local:parse-header($header as xs:string) as xs:string {
  let $regex := "(([a-z]{1,8})(-[a-z]{1,8})?)\s*(;\s*q\s*=\s*(1|0\.[0-9]+))?"
  let $flags := "i"
  let $format := "$2q=$5"
  return fn:replace(fn:lower-case($header), $regex, $format)
};

local:get-browser-lang()
```

If you've created an internationalized website lately, you've probably implemented some sort of language chooser widget in your site ui to allow your users