# Checking headers

**URL:** <https://www.ruby-forum.com/t/checking-headers/244697>\
**Category:** NGINX\
**Created:** [May 28, 2016, 9:49pm UTC](https://www.ruby-forum.com/t/checking-headers/244697 "2016-05-28T21:49:37Z")\
**Posts on this page:** 13\
**Page:** 1

<div class="post-metadata">

**Author:** ![Sadaf\_N](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/858c86/32.png) [@Sadaf\_N](https://www.ruby-forum.com/u/Sadaf_N)\
**Post date:** [May 28, 2016, 9:49pm UTC](https://www.ruby-forum.com/t/checking-headers/244697/1 "2016-05-28T21:49:37Z")

</div>

Is there any way with nginx to check a request’s headers and send back  
a 401 if the headers are not proper?

---

<div class="post-metadata">

**Author:** ![gennosuke](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/g/97f17d/32.png) [@gennosuke](https://www.ruby-forum.com/u/gennosuke)\
**Post date:** [May 30, 2016, 8:20pm UTC](https://www.ruby-forum.com/t/checking-headers/244697/2 "2016-05-30T20:20:08Z")

</div>

On Sat, May 28, 2016 at 12:48 PM, Larry M.  
[removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)  
wrote:

> Is there any way with nginx to check a request’s headers and send back  
> a 401 if the headers are not proper?

Yes, you can do with this via the ‘map’ and ‘if’ directives. A trivial  
example:

http {  
# if the “X-Foo” request header contains the phrase ‘data’, set  
$bar to 1; otherwise, set it to 0  
map $http\_x\_foo $bar {  
default 0;  
“~data” 1;  
}

```
server {
    location /t {
            if ($bar) {
                    return 401;
            }
    }

```

}

See also [Module ngx\_http\_map\_module](http://nginx.org/en/docs/http/ngx_http_map_module.html) and  
[Module ngx\_http\_rewrite\_module](http://nginx.org/en/docs/http/ngx_http_rewrite_module.html#if)

---

<div class="post-metadata">

**Author:** ![gennosuke](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/g/97f17d/32.png) [@gennosuke](https://www.ruby-forum.com/u/gennosuke)\
**Post date:** [May 31, 2016, 1:42pm UTC](https://www.ruby-forum.com/t/checking-headers/244697/3 "2016-05-31T13:42:15Z")

</div>

On Mon, May 30, 2016 at 2:19 PM, Robert P.  
[removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:

> Yes, you can do with this via the ‘map’ and ‘if’ directives. A trivial  
> server {  
> location /t {  
> if ($bar) {  
> return 401;  
> }  
> }  
> }
> 
> See also [Module ngx\_http\_map\_module](http://nginx.org/en/docs/http/ngx_http_map_module.html) and  
> [Module ngx\_http\_rewrite\_module](http://nginx.org/en/docs/http/ngx_http_rewrite_module.html#if)

I added this to the http section:

```
map $http_x_capdata_auth $not_auth {
    default 1;
    "authorized" 0;
}

```

and this to the location section:

```
        if ($not_auth) {
            return 401;
        }

```

and it’s always returning a 401, even if there is a header:

X-Capdata-Auth: authorized

And I doing something wrong here? How can I debug this?

---

<div class="post-metadata">

**Author:** ![gennosuke](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/g/97f17d/32.png) [@gennosuke](https://www.ruby-forum.com/u/gennosuke)\
**Post date:** [May 31, 2016, 3:25pm UTC](https://www.ruby-forum.com/t/checking-headers/244697/4 "2016-05-31T15:25:04Z")

</div>

On Tue, May 31, 2016 at 7:55 AM, Larry M. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)  
wrote:

> > > ```
> > > "~data" 1;
> > > 
> > > ```
> > > 
> > > See also [Module ngx\_http\_map\_module](http://nginx.org/en/docs/http/ngx_http_map_module.html) and
> 
> Looking with tcpdump I do not see that header field set. The request  
> is coming from a django app which is doing a redirect and I set the  
> header before the redirect. Guess I have to debug from that side.

I traced the django code all the way through to when the response is  
going out and I see this:

(Pdb) response.\_headers  
{‘x-capdata-auth’: (‘X-Capdata-Auth’, ‘authorized’), ‘content-type’:  
(‘Content-Type’, ‘text/html; charset=utf-8’), ‘location’: (‘Location’,  
‘[http://foo.bar.com:8000/workitem/12345](http://foo.bar.com:8000/workitem/12345)’), ‘vary’: (‘Vary’, ‘Cookie’)}

Any one have any ideas as to why it doesn’t seem to make it over to  
nginx?

---

<div class="post-metadata">

**Author:** ![gennosuke](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/g/97f17d/32.png) [@gennosuke](https://www.ruby-forum.com/u/gennosuke)\
**Post date:** [May 31, 2016, 1:56pm UTC](https://www.ruby-forum.com/t/checking-headers/244697/5 "2016-05-31T13:56:51Z")

</div>

On Tue, May 31, 2016 at 7:41 AM, Larry M. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)  
wrote:

> > ```
> > }
> > 
> > ```
> > 
> > [Module ngx\_http\_rewrite\_module](http://nginx.org/en/docs/http/ngx_http_rewrite_module.html#if)  
> > if ($not\_auth) {  
> > return 401;  
> > }
> 
> and it’s always returning a 401, even if there is a header:
> 
> X-Capdata-Auth: authorized
> 
> And I doing something wrong here? How can I debug this?

Looking with tcpdump I do not see that header field set. The request  
is coming from a django app which is doing a redirect and I set the  
header before the redirect. Guess I have to debug from that side.

---

<div class="post-metadata">

**Author:** ![gennosuke](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/g/97f17d/32.png) [@gennosuke](https://www.ruby-forum.com/u/gennosuke)\
**Post date:** [May 31, 2016, 3:46pm UTC](https://www.ruby-forum.com/t/checking-headers/244697/6 "2016-05-31T15:46:41Z")

</div>

On Tue, May 31, 2016 at 09:23:36AM -0400, Larry M. wrote:

> On Tue, May 31, 2016 at 7:55 AM, Larry M. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:
> 
> > > > On Sat, May 28, 2016 at 12:48 PM, Larry M. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)  
> > > > wrote:

Hi there,

> > > > > Is there any way with nginx to check a request’s headers and send back  
> > > > > a 401 if the headers are not proper?

> ‘[http://foo.bar.com:8000/workitem/12345](http://foo.bar.com:8000/workitem/12345)’), ‘vary’: (‘Vary’, ‘Cookie’)}
> 
> Any one have any ideas as to why it doesn’t seem to make it over to nginx?

There is a request from the client to nginx.

There is a response from nginx to the client.

There can be a request from nginx to its upstream, and a response from  
upstream to nginx.

Any of those requests and responses can include headers.

In your architecture, what “header” do you care about?

That should tell you which variable value to check.

> **[$http\_ - Module ngx\_http\_core\_module](http://nginx.org/en/docs/http/ngx_http_core_module.html#var_http_)**
>
> The PROXY protocol must be previously enabled by setting the proxy\_protocol parameter in the listen directive.

> **[$sent\_http\_ - Module ngx\_http\_core\_module](http://nginx.org/en/docs/http/ngx_http_core_module.html#var_sent_http_)**
>
> The PROXY protocol must be previously enabled by setting the proxy\_protocol parameter in the listen directive.

> **[$upstream\_http\_ - Module ngx\_http\_upstream\_module](http://nginx.org/en/docs/http/ngx_http_upstream_module.html#var_upstream_http_)**

are three different families of variables set within nginx.

Possibly one of them covers what you want?

## f

Francis D. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)

---

<div class="post-metadata">

**Author:** ![gennosuke](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/g/97f17d/32.png) [@gennosuke](https://www.ruby-forum.com/u/gennosuke)\
**Post date:** [May 31, 2016, 5:38pm UTC](https://www.ruby-forum.com/t/checking-headers/244697/7 "2016-05-31T17:38:51Z")

</div>

On Tue, May 31, 2016 at 10:26:26AM -0400, Larry M. wrote:

> On Tue, May 31, 2016 at 9:45 AM, Francis D. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:

Hi there,

> neither case does my config pick that up. This is what I have:
> 
> map $http\_x\_capdata\_auth $not\_auth {  
> default 1;  
> “authorized” 0;  
> }
> 
> Is that the correct way to check for that header value?

Yes. That checks for the request header from the client.

It works for me:

==  
http {  
map $http\_x\_capdata\_auth $not\_auth {  
default 1;  
“authorized” 0;  
}

# server { listen 8080; location / { if ($not\_auth) { return 401 “$http\_x\_capdata\_auth, $not\_auth\n”; } return 200 “$http\_x\_capdata\_auth, $not\_auth\n”; } } }

curl -v -H ‘X-CapData-Auth: authorized’ [http://127.0.0.1:8080/test](http://127.0.0.1:8080/test)  
 → HTTP/1.1 200 OK; authorized, 0

curl -v [http://127.0.0.1:8080/test](http://127.0.0.1:8080/test)  
 → HTTP/1.1 401 Unauthorized: , 1

> Is there a way for me to dump the headers that it sees on requests to port 8000?

Within nginx, probably the debug log is simplest.

Outside nginx: tcpdump, or ask the client what it sends.

## f

Francis D. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)

---

<div class="post-metadata">

**Author:** ![gennosuke](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/g/97f17d/32.png) [@gennosuke](https://www.ruby-forum.com/u/gennosuke)\
**Post date:** [May 31, 2016, 4:27pm UTC](https://www.ruby-forum.com/t/checking-headers/244697/8 "2016-05-31T16:27:35Z")

</div>

On Tue, May 31, 2016 at 9:45 AM, Francis D. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)  
wrote:

> > > Looking with tcpdump I do not see that header field set. The request
> 
> are three different families of variables set within nginx.
> 
> Possibly one of them covers what you want?

There are 2 ways requests get to port 8000, which is the port I want  
to check headers on.

One is via a C++ Qt app, and the other is from a python django app.

The C++ app sends the request directly to port 8000. With the django  
app a request is sent to port 8004 and django sends a 301 redirect to  
8000. In both cases the header field X-Capdata-Auth is set. And in  
neither case does my config pick that up. This is what I have:

map $http\_x\_capdata\_auth $not\_auth {  
default 1;  
“authorized” 0;  
}

Is that the correct way to check for that header value?

Is there a way for me to dump the headers that it sees on requests to  
port 8000?

---

<div class="post-metadata">

**Author:** ![gennosuke](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/g/97f17d/32.png) [@gennosuke](https://www.ruby-forum.com/u/gennosuke)\
**Post date:** [May 31, 2016, 6:34pm UTC](https://www.ruby-forum.com/t/checking-headers/244697/9 "2016-05-31T18:34:56Z")

</div>

On Tue, May 31, 2016 at 11:38 AM, Francis D. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)  
wrote:

> > One is via a C++ Qt app, and the other is from a python django app.
> 
> ```
> "authorized" 0;
> 
> ```
> 
> ==
> 
> Outside nginx: tcpdump, or ask the client what it sends.

Using curl I can see that ngixn is doing the right thing. Looking at  
the request coming out of the clients show the header being there.  
Using tcpdump I do not see the header. I know this is no longer an  
nginx question, but anyone know why that header would get dropped  
along the way?

---

<div class="post-metadata">

**Author:** ![gennosuke](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/g/97f17d/32.png) [@gennosuke](https://www.ruby-forum.com/u/gennosuke)\
**Post date:** [May 31, 2016, 10:20pm UTC](https://www.ruby-forum.com/t/checking-headers/244697/10 "2016-05-31T22:20:26Z")

</div>

On Tue, May 31, 2016 at 12:33:56PM -0400, Larry M. wrote:

> On Tue, May 31, 2016 at 11:38 AM, Francis D. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:
> 
> > On Tue, May 31, 2016 at 10:26:26AM -0400, Larry M. wrote:

Hi there,

> > > The C++ app sends the request directly to port 8000. With the django  
> > > app a request is sent to port 8004 and django sends a 301 redirect to  
> > > 8000. In both cases the header field X-Capdata-Auth is set. And in  
> > > neither case does my config pick that up. This is what I have:

> Using curl I can see that ngixn is doing the right thing. Looking at  
> the request coming out of the clients show the header being there.  
> Using tcpdump I do not see the header. I know this is no longer an  
> nginx question, but anyone know why that header would get dropped  
> along the way?

It sounds like your design is that your client sends a http request to  
port 8004; the http service there returns a 301 redirect to a url on  
port  
8000 and includes a particular response header; and you want your client  
to follow the redirect by making a new request to port 8000 and include  
a  
request header that mirrors the particular response header that you  
sent.

If you are using the client that you wrote, then you can make sure that  
it does that.

If you are using a general http client, it is unlikely to do that.

Perhaps an alternate design involving reverse-proxying would be valid?

Cheers,

## f

Francis D. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)

---

<div class="post-metadata">

**Author:** ![gennosuke](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/g/97f17d/32.png) [@gennosuke](https://www.ruby-forum.com/u/gennosuke)\
**Post date:** [May 31, 2016, 10:49pm UTC](https://www.ruby-forum.com/t/checking-headers/244697/11 "2016-05-31T22:49:38Z")

</div>

On Tue, May 31, 2016 at 4:19 PM, Francis D. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)  
wrote:

> request header that mirrors the particular response header that you sent.  
> With the django app, what you are saying is correct.

> If you are using the client that you wrote, then you can make sure that  
> it does that.
> 
> If you are using a general http client, it is unlikely to do that.

I am knida new to all this. The apps were written by someone who quit  
and then this was all dropped in my lap. I thought I was clear on what  
a client and server were in life, in this app it’s somewhat screwy.  
What is behind port 8000 is nginx routing to some Angular code that  
sends a request out. So the Angular code, although client side, is  
acting like a server in that it is invoked in response to a request.  
Then it turns about and acts like a client and sends a request out.  
So, who’s the server here? nginx?

There are 2 approved ways to send a request to port 8000. One is from  
an app we wrote that is in C++ and it directly sends the request to  
port 8000. These requests are always previously authenticated and are  
good to go. The second is from a django endpoint listening on 8004. It  
does some authentication and if all is good, redirects to 8000. So  
with both of these cases I want to request to port 8000 to go through.

Then, of course, there are myriad other ways for a request to get port  
8000 - from a browser, curl, wget, etc. In all of these cases I want  
the request to be blocked and return a 401.

I was hoping to do this with a custom header, but that appears not to  
work. Can anyone recommend another way to achieve this?

> Perhaps an alternate design involving reverse-proxying would be valid?

How would that help me?

Thanks!

---

<div class="post-metadata">

**Author:** ![gennosuke](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/g/97f17d/32.png) [@gennosuke](https://www.ruby-forum.com/u/gennosuke)\
**Post date:** [June 1, 2016, 1:06am UTC](https://www.ruby-forum.com/t/checking-headers/244697/12 "2016-06-01T01:06:55Z")

</div>

On Tue, May 31, 2016 at 04:48:19PM -0400, Larry M. wrote:

> On Tue, May 31, 2016 at 4:19 PM, Francis D. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:
> 
> > On Tue, May 31, 2016 at 12:33:56PM -0400, Larry M. wrote:

Hi there,

> > If you are using a general http client, it is unlikely to do that.
> 
> I am knida new to all this. The apps were written by someone who quit  
> and then this was all dropped in my lap.

It might be instructive for you to find out _why_ they quit.

If it was related to them being required to implement a design which  
they  
knew can’t possibly work, it would be good for you to learn that early.

But that’s beside the point, here.

> I thought I was clear on what  
> a client and server were in life, in this app it’s somewhat screwy.

Probably a good thing you can do for you, is take a pencil and paper  
and write down the intended data flow of this application.

Until you are happy that the design is right, you probably can’t accept  
responsibility for implementing it.

In general, the app is a chain of events. At each point, one client is  
making one request of one server.

When you can see the data flow design, it will be clearer to you.

> What is behind port 8000 is nginx routing to some Angular code that  
> sends a request out. So the Angular code, although client side, is  
> acting like a server in that it is invoked in response to a request.

I don’t follow all of those words, but that’s ok: I don’t have to.

> Then it turns about and acts like a client and sends a request out.  
> So, who’s the server here? nginx?

Whatever is making the request is the client at this instant; whatever  
is receiving the request is the server at this instant.

> There are 2 approved ways to send a request to port 8000. One is from  
> an app we wrote that is in C++ and it directly sends the request to  
> port 8000. These requests are always previously authenticated and are  
> good to go. The second is from a django endpoint listening on 8004. It  
> does some authentication and if all is good, redirects to 8000. So  
> with both of these cases I want to request to port 8000 to go through.
> 
> Then, of course, there are myriad other ways for a request to get port  
> 8000 - from a browser, curl, wget, etc. In all of these cases I want  
> the request to be blocked and return a 401.

nginx on port 8000 does not care whether the request came from your C++  
app or from my curl command.

All it cares about is what it is configured to do: which is to accept a  
http request that includes the “I promise I am authorised” token.

browser, curl, wget, etc, can all include that token, without touching  
your django app or your C++ program.

If that is your design, and the authorisation actually matters for  
anything, then your design is broken and you need to re-design.

> I was hoping to do this with a custom header, but that appears not to  
> work. Can anyone recommend another way to achieve this?

One possibility might be to use auth\_request  
([Module ngx\_http\_auth\_request\_module](http://nginx.org/r/auth_request)) within nginx to authorise-and-return  
the content in one step (as far as the client is concerned) in nginx.

Another possibility might be to use “X-Accel-Redirect” from the  
reverse-proxied authorisation-checker. Again, from the client  
perspective,  
the request with credentials results in the desired response directly.

The current two-step process of one request with credentials which are  
checked, returning a “I am authorised” token; followed by another  
request  
with that token which the second server does not authenticate at all;  
leads to you being able to use “curl” to pretend to be authorised.

> > Perhaps an alternate design involving reverse-proxying would be valid?
> 
> How would that help me?

As above, nginx could reverse-proxy to the authorisation checker; or  
alternatively the django app could reverse-proxy to nginx; and then you  
could put in external (firewall?) rules which mean that only your C++  
app and your django app can get to nginx on port 8000.

Good luck with it,

## f

Francis D. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)

---

<div class="post-metadata">

**Author:** ![gennosuke](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/g/97f17d/32.png) [@gennosuke](https://www.ruby-forum.com/u/gennosuke)\
**Post date:** [June 1, 2016, 10:46pm UTC](https://www.ruby-forum.com/t/checking-headers/244697/13 "2016-06-01T22:46:40Z")

</div>

On Tue, May 31, 2016 at 7:06 PM, Francis D. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)  
wrote:

> > > request header that mirrors the particular response header that you sent.
> > 
> > With the django app, what you are saying is correct.
> > 
> > > If you are using the client that you wrote, then you can make sure that  
> > > it does that.
> > > 
> > > If you are using a general http client, it is unlikely to do that.
> > 
> > I am knida new to all this. The apps were written by someone who quit  
> > and then this was all dropped in my lap.

Francis, I really appreciate the time you took to send such a complete  
and thoughtful reply.

> It might be instructive for you to find out _why_ they quit.

I’ll never know for sure, as he was gone before I got there. But I  
have some pretty good guesses.

> If it was related to them being required to implement a design which they  
> knew can’t possibly work, it would be good for you to learn that early.

He was the one who designed and built it, and it seems overly  
complicated to me. But I like to give people the benefit of the doubt  
and think he had his reasons.

> But that’s beside the point, here.
> 
> > I thought I was clear on what  
> > a client and server were in life, in this app it’s somewhat screwy.
> 
> Probably a good thing you can do for you, is take a pencil and paper  
> and write down the intended data flow of this application.

Yes, that was one of the first things I did when I took the job. I  
understand the flow, but I don’t understand why it was done in the way  
it was.

> Until you are happy that the design is right, you probably can’t accept  
> responsibility for implementing it.

It’s implemented already and it functionally works, but it has no  
security or authentication at all. That is what I was asked to add.  
And they wanted it done ASAP since they were hanging out naked.

> In general, the app is a chain of events. At each point, one client is  
> making one request of one server.
> 
> When you can see the data flow design, it will be clearer to you.
> 
> > What is behind port 8000 is nginx routing to some Angular code that  
> > sends a request out. So the Angular code, although client side, is  
> > acting like a server in that it is invoked in response to a request.
> 
> I don’t follow all of those words, but that’s ok: I don’t have to.

Initially I didn’t find it confusing, but perhaps that is from my  
ignorance. But when I talked to people about it they were always  
confused. I didn’t see why there were so confused, but then it struck  
me - the Angular code acts like a server and in everyone’s mind, that  
is not what client side code does. I was trying in the Angular code to  
get info on the request it was serving. But from Angular’s point of  
view, it wasn’t serving a request - it was just being invoked and it  
sends out a request. The fact that it was invoked because nginx got a  
request on port 8000 was not known to Angular. So me trying to do  
server type things (like look a the request headers) made no sense in  
client side code.

> > does some authentication and if all is good, redirects to 8000. So  
> > http request that includes the “I promise I am authorised” token.
> 
> browser, curl, wget, etc, can all include that token, without touching  
> your django app or your C++ program.

Yes, I realize all that. I was going for some short term security by  
obscurity. Anything is better then the nothing they had.

> If that is your design, and the authorisation actually matters for  
> anything, then your design is broken and you need to re-design.

What I ended up doing was to embed the auth info in the URL parameters  
and then encrypt that. Got me by for the moment. Down the road I’ll do  
something better.

> > I was hoping to do this with a custom header, but that appears not to  
> > work. Can anyone recommend another way to achieve this?
> 
> One possibility might be to use auth\_request  
> ([Module ngx\_http\_auth\_request\_module](http://nginx.org/r/auth_request)) within nginx to authorise-and-return  
> the content in one step (as far as the client is concerned) in nginx.
> 
> Another possibility might be to use “X-Accel-Redirect” from the  
> reverse-proxied authorisation-checker. Again, from the client perspective,  
> the request with credentials results in the desired response directly.

Thanks I will look into those solutions.

> The current two-step process of one request with credentials which are  
> checked, returning a “I am authorised” token; followed by another request  
> with that token which the second server does not authenticate at all;  
> leads to you being able to use “curl” to pretend to be authorised.

Yes, if someone knew what header field and value to use.

> > > Perhaps an alternate design involving reverse-proxying would be valid?
> > 
> > How would that help me?
> 
> As above, nginx could reverse-proxy to the authorisation checker; or  
> alternatively the django app could reverse-proxy to nginx; and then you  
> could put in external (firewall?) rules which mean that only your C++  
> app and your django app can get to nginx on port 8000.
> 
> Good luck with it,

Thanks again!

-Larry