# HTTP configuration (part 2)

Here are the rest of the Liberator configuration items that define how Liberator handles HTTP connections with clients.

**💡 TIP**\
Liberator’s supplied with a built-in HTTP [Config blade](../deployment-framework/cdf-blade-types.md) that’s automatically activated when you install the Liberator (see [Built-in blades](../deployment-framework/cdf-built-in-blades.md)). For more about how to change the configuration of this blade, see How can I... [Configure how Liberator handles HTTP connections](liberator-configure-how-liberator-handles-http-connections.md).

For more HTTP-related configuration items, see [HTTP configuration (part 1)](liberator-http-configuration-part-1.md).

## add-authdir

`add-authdir` specifies an HTTP-authenticated directory.

**Syntax:**

```
add-authdir
   xref:check-module[check-module]     [type]
   xref:name[name]             [string]
   xref:password[password]         [string array]
   xref:realm[realm]            [string]
   xref:secure-passwords[secure-passwords] [boolean]
   xref:username[username]         [string array]
end-authdir
```

| Option | Type | Default | Description |
| --- | --- | --- | --- |
| <a name="check-module"></a>`check-module` | boolean | `FALSE` | When `check-module` is `TRUE`, the Liberator’s [auth module](liberator-user-authentication-and-permissioning.md#how-does-liberator-implement-user-authentication-and-permissioning) is used to authorise a user’s access to the HTTP directory specified in [name](#name), instead of using the list of [username](#username)s and [password](#password)s supplied in this `add-authdir` item. For example, if the Auth module is cfgauth, the authorised usernames and passwords are defined in the [username](liberator-cfgauth-configuration.md#username) and [password](liberator-cfgauth-configuration.md#password) options of the cfgauth configuration item [add-user](liberator-cfgauth-configuration.md#add-user). |
| <a name="name"></a>`name` | string | `/status` | The full HTTP directory name. The default is the Liberator’s status page. |
| <a name="password"></a>`password` | string array | `admin` | A space-separated list of passwords. Each password relates to the [username](#username) in the corresponding position in the list. See [Note 1](#note-1) below. The passwords can be encrypted in MD5 hash format so that they are secure; in this case, set [secure-passwords](#secure-passwords) to `TRUE`. |
| <a name="realm"></a>`realm` | string | `Liberator Admin` | The HTTP basic authentication realm. (This string is shown in the Liberator login window that pops up at the client when the login isn’t through [KeyMaster](../keymaster/index.md) single sign-on.) |
| <a name="secure-passwords"></a>`secure-passwords` | boolean | `FALSE` | When `secure-passwords` is `TRUE`, the password received for a [username](#username) is encrypted in MD5 hash format before being validated against the corresponding password defined in the [password](#password) option. |
| <a name="username"></a>`username` | string array | `admin` | A space-separated list of usernames defining the users who can access the HTTP directory specified in [name](#name). See [Note 1](#note-1) below. |

**<a name="note-1"></a>Note 1:**

You can specify multiple usernames and passwords in the following ways: either as space-separated lists, as individual entries, or a combination of the two.

_Example 1:_

```
add-authdir
   username   Alf Bill Carl Dave
   password   pwA pwB pwC pwD
end-authdir
```

In the above example user ``Alf`’s password is `pwA`, user ``Bill`’s password is `pwB`, and so on.

_Example 2:_

```
add-authdir
   username   Alf
   password   pwA
   username   Bill
   password   pwB
   username   Carl Dave
   password   pwC pwD
end-authdir
```

In the above example user ``Alf`’s password is still `pwA`, but it’s been specified in a `password` option that immediately follows the `username` option for `Alf`, and similarly for user `Bill` whose password is `pwB`.

## add-useragent

`add-useragent` enables various HTTP protocol extensions for a specific browser or browsers, as identified by the browser(s) user agent string.

**Syntax:**

```
add-useragent
   xref:useragent-pattern[useragent-pattern] [string]
   xref:extensions[extensions]        flag1|flag2|flag3|...
end-useragent
```

| Option | Type | Default | Description |
| --- | --- | --- | --- |
| <a name="useragent-pattern"></a>`useragent-pattern` | string | +[none]+ | A regular expression that Liberator uses to match the user agent string sent to it from a client’s browser. For examples of user agent strings, see [User-Agent - HTTP](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/User-Agent) on the Mozilla Developer Network. You can also identify the user agent string sent to Liberator from a particular browser by logging into the Liberator from the browser and then looking in the Liberator’s [http-access-log](liberator-http-configuration-part-1.md#http-access-log). |
| <a name="extensions"></a>`extensions` | string | Value of [http-extensions](liberator-http-configuration-part-1.md#http-extensions) | Flags that enable various HTTP protocol extensions. These flags allow you to turn on HTTP features that can improve utilisation of the client-Liberator connection for browsers whose user agent strings match the value of the [useragent-pattern](#useragent-pattern) option. Valid values are as for the [http-extensions](liberator-http-configuration-part-1.md#http-extensions) configuration item. For browsers that match [useragent-pattern](#useragent-pattern), the `extensions` option adds to and/or overrides the settings of the [http-extensions](liberator-http-configuration-part-1.md#http-extensions) configuration item. You can specify the flags in one extensions option, like this: |
```
http-extensions flag1|flag2|flag3
` or in multiple options, like this: |
```
http-extensions flag1
http-extensions flag2
http-extensions flag3
` See the examples below. |

**Examples:**

_Example 1_

```
add-useragent
   useragent-pattern MSIE
   extensions force-type5-chunked
end-useragent
```

This example forces Liberator to use the HTTP chunked-transfer encoding when the StreamLink connection type is "Streaming JavaScript via IFrame" and Server-Sent Events are turned off. It’s used when the client application is running in any version of the Microsoft Internet Explorer browser.

_Example 2_

```
add-useragent
   useragent-pattern "MSIE 11\."
   allow-extensions force-type5-chunked
end-useragent
```

This example does the same as Example 1 above, but only applies to version 11 releases of the Microsoft Internet Explorer browser; that is, all browsers that return a user agent string containing the string "MSIE 11."

_Example 3_

```
add-useragent
   useragent-pattern Chrome
   extensions allow-sse-deflate|allow-ws-permessage-deflate
end-useragent
```

This example allows Liberator to negotiate with the Chrome browser to use compression for the HTML5 Server-Sent Events connection type and to use DEFLATE compression of Websocket frames.

---

**See also:**

* How can I ... [Configure how Liberator handles HTTP connections](liberator-configure-how-liberator-handles-http-connections.md)
* Reference: [HTTP configuration (part 1)](liberator-http-configuration-part-1.md)
* Reference: [HTTPS configuration](liberator-https-configuration.md)
* Reference: [RTTP configuration](liberator-rttp-configuration.md)