5

I'm having an issue when I change my jetty distro from 9.2 to 9.3. Under 9.2 my app works flawlessly however when running the same war file and connecting from the same client I get the following error messages when running under 9.3:

015-08-30 14:55:32.174:WARN:oejh.HttpParser:qtp1100439041-12: Illegal character 0x20 in state=HEADER_IN_NAME for buffer HeapByteBuffer@26dab36[p=62,l=654,c=8192,r=592]={POST /api/v1/time...0.1:8080\r\nKey <<<Info Header: ...erica/Toronto"}>>>\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00...\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00}

2015-08-30 14:55:32.175:WARN:oejh.HttpParser:qtp1100439041-12: bad HTTP parsed: 400 Illegal character 0x20 for HttpChannelOverHttp@6765bf81{r=0,c=false,a=IDLE,uri=-}

From what I understand, there is an illegal character in the header, however why does one version throw this error and the other does not?

Also I am using Apache httpclient 4.4.1 to send the data.

Joakim Erdfelt
  • 46,896
  • 7
  • 86
  • 136
andy9775
  • 372
  • 3
  • 10

1 Answers1

20

The upgrade from Jetty 9.2 to 9.3 meant you entered in the new world of HTTP/1.1 updated specs and rfcs, and new HTTP/2 requirements, even including changes to the HTTP/1.1 to support HTTP/2 upgrade (h2c).

Jetty 9.2 followed RFC2616 (Now Obsoleted by: RFC7230, RFC7231, RFC7232, RFC7233, RFC7234, RFC7235 and Updated by: RFC2817, RFC5785, RFC6266, RFC6585)

Jetty 9.3 follows the updates to the venerable (from 1999!) RFC2616 spec. Many things that were valid in the past are no longer valid. We also dropped support for HTTP/0.9 in Jetty 9.3

There are a many parts of HTTP/1.1 that were tidied up to take advantage of the updated RFCs, some of them might have bit you.

Looking at the spec, RFC7230: Section 3.2 - Header Fields, you see the header field declared as...

 header-field   = field-name ":" OWS field-value OWS

 field-name     = token
 field-value    = *( field-content / obs-fold )
 field-content  = field-vchar [ 1*( SP / HTAB ) field-vchar ]
 field-vchar    = VCHAR / obs-text

 obs-fold       = CRLF 1*( SP / HTAB )
                ; obsolete line folding
                ; see Section 3.2.4

with token defined in RFC7230: Appendix B - Collected ABNF as ...

tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" / "+" / "-" / "." /
        "^" / "_" / "`" / "|" / "~" / DIGIT / ALPHA
token = 1*tchar

which means that your " " (space) in "Info Header:" is invalid per spec.

It would be better if it were "Info-Header" or more accurately following the spec as "X-Info-Header" (so as to not conflict with spec reserved header names)

Community
  • 1
  • 1
Joakim Erdfelt
  • 46,896
  • 7
  • 86
  • 136
  • Well, it was invalid in all earlier versions of HTTP as well. – Julian Reschke Jun 27 '18 at 13:01
  • 1
    While its true that `token` never allowed the `" " ` (space), the header parsing rules of early specs essentially said to look for the first `:` (colon) and what's before the colon is the token, contradicting itself. Thankfully these kinds of contradictions have been corrected (slowly) over the years with the updated specs. – Joakim Erdfelt Jun 27 '18 at 14:43
  • Which "header parsing rules of early specs"? Pointer, please. – Julian Reschke Jun 27 '18 at 19:04
  • is there a way to allow this traffic as making change at client end would break backward compatibility? – Vishal T Jul 27 '20 at 06:53
  • @VishalT The changes in the specs were done to remove/eliminate/prevent security issues that lax behaviors of the prior spec caused. Your need for backward compatibility it running into a stronger need for security/safety. – Joakim Erdfelt Jul 27 '20 at 13:31