Oh my.... let me see if we can easily fix this 😂

> Am 12.05.2017 um 15:29 schrieb Roger <notifications@github.com>:
> 
> I don't know if it's worth pursuing but I came yesterday across a network appliance that seemed to perform malformed HTTP based health checks against our Netty application.
> 
> The HTTP requests looked like this GET /\r\n without the version and HttpVersion line 63 was throwing Exceptions.
> 
> Turns out it's HTTP/0.9 as per RFC 1945 (see section 3.1)
> 
> If the protocol version is not specified, the recipient must assume that the message is in the simple HTTP/0.9 format.
> 
> Expected behavior
> 
> Actual behavior
> 
> Steps to reproduce
> 
> Minimal yet complete reproducer code (or URL to code)
> 
> Netty version
> 
> JVM version (e.g. java -version)
> 
> OS version (e.g. uname -a)
> 
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub, or mute the thread.
> 
 You really want to implement HTTP/0.9 from the era of before 1996, when almost no web browser worked correctly?

For example, Chrome removed HTTP/0.9 https://developers.google.com/web/updates/2016/09/chrome-54-deprecations#http09_deprecated

> HTTP/0.9 is the predecessor to HTTP/1.x. It lacks many features of its successors. A particular concern for the modern web is its lack of response headers. Without them, there's no way to verify that an HTTP/0.9 response is really an HTTP/0.9 response. This can cause several problems. Examples include, among other problems:
> - Clients that treat certain error responses as valid HTTP/0.9 responses.
> - Servers that fail to close the request socket causing clients to treat responses as a hanging GET which either stays alive eternally or until a user navigates from a page that made the request.
> - Servers that are unable to indicate to the browser that a request failed, which can cause problems with caching heuristics.

> The only foolproof way to fix issues with HTTP/0.9 is to remove support altogether. Which is why support for HTTP/0.9 is removed in Chrome 54.

Please think twice before opening a can of worms.  Maybe augment [HttpVersion line 63](https://github.com/netty/netty/blob/4.1/codec-http/src/main/java/io/netty/handler/codec/http/HttpVersion.java#L63) from throwing `IllegalArgumentException("text is empty")` to `IllegalArgumentException("text is empty, possibly HTTP/0.9")` and call it a day.

The confusing thing about this issue was that Netty was sending these `HttpRequestDecoder#createInvalidMessage()` messages down the pipeline with the decoder state's exception message being "text is empty".  Sounds good... want to do a pr?

> Am 25.05.2017 um 16:01 schrieb Roger <notifications@github.com>:
> 
> Maybe augment HttpVersion line 63 from throwing IllegalArgumentException("text is empty") to IllegalArgumentException("text is empty, possibly HTTP/0.9") and call it a day.
> 
> The confusing thing about this issue was that Netty was sending these HttpRequestDecoder#createInvalidMessage() messages down the pipeline with the decoder state's exception message being "text is empty".
> 
> —
> You are receiving this because you were assigned.
> Reply to this email directly, view it on GitHub, or mute the thread.
> 
 @normanmaurer sure, consider it done. :) 👌

> Am 25.05.2017 um 17:19 schrieb Roger <notifications@github.com>:
> 
> @normanmaurer sure, consider it done. :)
> 
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub, or mute the thread.
> 
 Fixed by https://github.com/netty/netty/pull/6780
Handle missing version in HTTP request line (a.k.a HTTP/0.9)
I don't know if it's worth pursuing but I came yesterday across a network appliance that seemed to perform malformed HTTP based health checks against our Netty application.

The HTTP requests looked like this `GET /\r\n` without the version and [HttpVersion line 63](https://github.com/netty/netty/blob/4.1/codec-http/src/main/java/io/netty/handler/codec/http/HttpVersion.java#L63) was throwing Exceptions.

Turns out it's HTTP/0.9 as per [RFC 1945](https://www.ietf.org/rfc/rfc1945.txt) (see section 3.1)

> If the protocol version is not specified, the recipient must assume that the message is in the simple HTTP/0.9 format.

### Expected behavior

### Actual behavior

### Steps to reproduce

### Minimal yet complete reproducer code (or URL to code)

### Netty version

### JVM version (e.g. `java -version`)

### OS version (e.g. `uname -a`)

codec-http/src/main/java/io/netty/handler/codec/http/HttpVersion.java
codec-http/src/main/java/io/netty/handler/codec/http/HttpVersion.java
diff --git a/codec-http/src/main/java/io/netty/handler/codec/http/HttpVersion.java b/codec-http/src/main/java/io/netty/handler/codec/http/HttpVersion.java
index 806a1b7fdef..352ea848c52 100644
--- a/codec-http/src/main/java/io/netty/handler/codec/http/HttpVersion.java
+++ b/codec-http/src/main/java/io/netty/handler/codec/http/HttpVersion.java
@@ -60,7 +60,7 @@ public static HttpVersion valueOf(String text) {
         text = text.trim();
 
         if (text.isEmpty()) {
-            throw new IllegalArgumentException("text is empty");
+            throw new IllegalArgumentException("text is empty (possibly HTTP/0.9)");
         }
 
         // Try to match without convert to uppercase first as this is what 99% of all clients
