# HTTP request and RFC

**URL:** <https://discuss.elastic.co/t/http-request-and-rfc/84056>\
**Category:** Elasticsearch\
**Created:** [April 28, 2017, 8:17pm UTC](https://discuss.elastic.co/t/http-request-and-rfc/84056 "2017-04-28T20:17:39Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![jprante](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/jprante/32/44941_2.png) [@jprante](https://discuss.elastic.co/u/jprante)\
**Post date:** [April 28, 2017, 8:17pm UTC](https://discuss.elastic.co/t/http-request-and-rfc/84056/1 "2017-04-28T20:17:39Z")

</div>

Hi,

the HTTP 1.1 spec defines

> **[RFC 7230: Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing](https://datatracker.ietf.org/doc/html/rfc7230)**
>
> The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document provides an overview of HTTP architecture and its associated terminology, defines the "http"...

> Once an inbound connection is obtained, the client sends an HTTP  
> request message (Section 3) with a request-target derived from the  
> target URI. There are four distinct formats for the request-target,  
> depending on both the method being requested and whether the request  
> is to a proxy.

> ```
> request-target = origin-form
> 
> ```

```
                / absolute-form
                / authority-form
                / asterisk-form

```

and in

> **[RFC 7230: Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing](https://datatracker.ietf.org/doc/html/rfc7230)**
>
> The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document provides an overview of HTTP architecture and its associated terminology, defines the "http"...

> To allow for transition to the absolute-form for all requests in some  
> future version of HTTP, a server MUST accept the absolute-form in  
> requests, even though HTTP/1.1 clients will only send them in  
> requests to proxies.

But when I send the following HTTP request to Elasticsearch

```
POST http://localhost:9200/_search HTTP/1.1
host: localhost:9200
date: Fri, 28 Apr 2017 19:30:04 GMT
content-length: 42
content-type: application/json

{"query":{"match":{"_all":"Hello World"}}}

```

for example with a command like

> cat http-uri-test.txt | nc localhost 9200

the following response is returned

```
HTTP/1.1 400 Bad Request
content-type: text/plain; charset=UTF-8
content-length: 74

No handler found for uri [http://localhost:9200/_search] and method [POST]

```

I think it would be nice for Elasticsearch to support the full HTTP spec. Should I open an issue?

---

<div class="post-metadata">

**Author:** ![warkolm](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/warkolm/32/39224_2.png) [@warkolm](https://discuss.elastic.co/u/warkolm)\
**Post date:** [April 30, 2017, 10:19pm UTC](https://discuss.elastic.co/t/http-request-and-rfc/84056/2 "2017-04-30T22:19:20Z")

</div>

> [@jprante](#):
>
> Should I open an issue?

Yes please 😃

---

<div class="post-metadata">

**Author:** ![jasontedor](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/jasontedor/32/66992_2.png) [@jasontedor](https://discuss.elastic.co/u/jasontedor)\
**Post date:** [May 2, 2017, 7:50pm UTC](https://discuss.elastic.co/t/http-request-and-rfc/84056/3 "2017-05-02T19:50:07Z")

</div>

I concur, this is a spec violation, and I spent some time looking into what would be involved in fixing it and it has me left wondering whether or not we should indeed fix this.

To be clear, a client should not be sending a request with a request target in absolute form like this.

Yet, it's easy to add code that handles receiving a request in this form, the complexity arises when validating such a request. What you don't want is this:

```auto
GET http://www.example.com:80/_cluster/state?pretty=true HTTP/1.1

```

sent to an Elasticsearch node and have it route this to the REST cluster state handler because Elasticsearch is not listening on port 80 on any interface with an address that `www.example.com` resolves to. However, this then means doing an arbitrary DNS lookup here to find out if the request is valid or not and that's a giant no-no. So I'm left thinking whether or not we really need to do this, with maybe the only thing being actually flat-out rejecting requests in this form (yes, I know this would be violating the spec but I'm okay with that in some cases and this might be such a case).

I will solicit thoughts from others.

---

<div class="post-metadata">

**Author:** ![Clinton\_Gormley](https://avatars.discourse-cdn.com/v4/letter/c/50afbb/32.png) [@Clinton\_Gormley](https://discuss.elastic.co/u/Clinton_Gormley)\
**Post date:** [May 3, 2017, 8:02am UTC](https://discuss.elastic.co/t/http-request-and-rfc/84056/4 "2017-05-03T08:02:52Z")

</div>

I agree with Jason that supporting the `absolute-form` could expose us to attack vectors like DOS on a slow DNS lookup. What we could do is to compare the hostname with the value of the `host` header and reject anything that is different. I'm not sure that would really be spec compliant though...

And to what end?

[RFC 7230 - Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing](https://tools.ietf.org/html/rfc7230#section-5.3.1) says:

> When making a request directly to an origin server, other than a  
> CONNECT or server-wide OPTIONS request (as detailed below), a client  
> MUST send only the absolute path and query components of the target  
> URI as the request-target.

And yes, [RFC 7230 - Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing](https://tools.ietf.org/html/rfc7230#section-5.3.2) says

> To allow for transition to the absolute-form for all requests in some  
> future version of HTTP, a server MUST accept the absolute-form in  
> requests, even though HTTP/1.1 clients will only send them in  
> requests to proxies.

but we already have a [future version of HTTP](https://tools.ietf.org/html/rfc7540) which changes the protocol dramatically in a different direction.

We'd essentially be adding code that is executed on every request for a potential future change that, in all probability, will never occur.

---

<div class="post-metadata">

**Author:** ![jasontedor](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/jasontedor/32/66992_2.png) [@jasontedor](https://discuss.elastic.co/u/jasontedor)\
**Post date:** [May 3, 2017, 5:33pm UTC](https://discuss.elastic.co/t/http-request-and-rfc/84056/5 "2017-05-03T17:33:00Z")

</div>

Thanks @Clinton_Gormley, I think we will not proceed with changing anything here then.

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\
**Post date:** [May 31, 2017, 5:44pm UTC](https://discuss.elastic.co/t/http-request-and-rfc/84056/6 "2017-05-31T17:44:42Z")

</div>

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.
