0x00d0: 7469 6f6e 2f6a 736f 6e0d 0a55 7365 722d tion/json..User- 0x00e0: 4167 656e 743a 0d0a 436f 6e6e 6563 7469 Agent:..Connecti
Here's your problem. You have a Header "User-Agent" without a value. This syntax is only valid in the deprecated RFC2616. If you want a Header without a value in the current RFC7230 it should be ... Content-Type: application/json User-Agent: "" Connection: close Fix that, try again. Either remove the field entirely, or make it's value say double-quote. Joakim Erdfelt / [email protected] On Sun, Apr 21, 2019 at 11:00 PM Patrick Dirks <[email protected]> wrote: > Hi Olivier, > > Thanks a lot - that’ll be the missing link. For now, I’m OK working with > 9.3.x to figure out where things are going so fundamentally off the rails. > There’s got to be something painfully obvious I’m missing somehow. Greg > Wilkins just pointed out they test their builds sending requests as little > as 1 byte at a time so it can’t be as simple as 1-vs-2 packets. There’s > probably something in how the cpprest client stubs are generating the > request, but darned if I can see it. > > As I just wrote to Greg, > > I believe the call is being dispatched as soon as the headers arrive > because in the ‘tcpdump’ trace I see only the headers go out and > immediately the response comes back (with an error). See below for a > (lightly censored) example out of the trace: > > 16:22:30.919766 IP pdirks-dev-linux.eng.vmware.com.49250 > > pdirks-dev-linux.eng.vmware.com.http-alt: Flags [P.], seq 1:207, ack 1, win > 342, options [nop,nop,TS val 3457687594 ecr 3457687594], length 206: HTTP: > PUT /VMware-XXX/XXX-backend/1.0/hosts HTTP/1.1 > 0x0000: 4500 0102 09aa 4000 4006 ea65 0a14 98df E.....@[email protected].... > 0x0010: 0a14 98df c062 1f90 2b24 0906 cfec aed1 .....b..+$...... > 0x0020: 8018 0156 46db 0000 0101 080a ce18 202a ...VF..........* > 0x0030: ce18 202a 5055 5420 2f56 4d77 6172 652d ...*PUT./VMware- > 0x0040: 5858 582f 5858 582d 6261 636b 656e 642f XXX/XXX-backend/ > 0x0050: 312e 302f 686f 7374 7320 4854 5450 2f31 1.0/hosts.HTTP/1 > 0x0060: 2e31 0d0a 486f 7374 3a20 7064 6972 6b73 .1..Host:.pdirks > 0x0070: 2d64 6576 2d6c 696e 7578 2e65 6e67 2e76 -dev-linux.eng.v > 0x0080: 6d77 6172 652e 636f 6d3a 3830 3830 0d0a mware.com:8080.. > 0x0090: 4163 6365 7074 3a61 7070 6c69 6361 7469 Accept:applicati > 0x00a0: 6f6e 2f6a 736f 6e0d 0a43 6f6e 7465 6e74 on/json..Content > 0x00b0: 2d4c 656e 6774 683a 3139 0d0a 436f 6e74 -Length:19..Cont > 0x00c0: 656e 742d 5479 7065 3a61 7070 6c69 6361 ent-Type:applica > 0x00d0: 7469 6f6e 2f6a 736f 6e0d 0a55 7365 722d tion/json..User- > 0x00e0: 4167 656e 743a 0d0a 436f 6e6e 6563 7469 Agent:..Connecti > 0x00f0: 6f6e 3a20 4b65 6570 2d41 6c69 7665 0d0a on:.Keep-Alive.. > 0x0100: 0d0a .. > 16:22:30.923503 IP pdirks-dev-linux.eng.vmware.com.http-alt > > pdirks-dev-linux.eng.vmware.com.49250: Flags [P.], seq 1:248, ack 226, > win 350, options [nop,nop,TS val 3457687598 ecr 3457687594], length 247: > HTTP: HTTP/1.1 400 Bad Request > 0x0000: 4500 012b ae7e 4000 4006 4568 0a14 98df E..+.~@[email protected].... > 0x0010: 0a14 98df 1f90 c062 cfec aed1 2b24 09e7 .......b....+$.. > 0x0020: 8018 015e 4704 0000 0101 080a ce18 202e ...^G........... > 0x0030: ce18 202a 4854 5450 2f31 2e31 2034 3030 ...*HTTP/1.1.400 > 0x0040: 2042 6164 2052 6571 7565 7374 0d0a 4461 .Bad.Request..Da > 0x0050: 7465 3a20 5375 6e2c 2032 3120 4170 7220 te:.Sun,.21.Apr. > 0x0060: 3230 3139 2032 333a 3232 3a33 3020 474d 2019.23:22:30.GM > 0x0070: 540d 0a41 6363 6573 732d 436f 6e74 726f T..Access-Contro > 0x0080: 6c2d 416c 6c6f 772d 4f72 6967 696e 3a20 l-Allow-Origin:. > 0x0090: 2a0d 0a41 6363 6573 732d 436f 6e74 726f *..Access-Contro > 0x00a0: 6c2d 416c 6c6f 772d 4d65 7468 6f64 733a l-Allow-Methods: > 0x00b0: 2047 4554 2c20 504f 5354 2c20 4445 4c45 .GET,.POST,.DELE > 0x00c0: 5445 2c20 5055 540d 0a41 6363 6573 732d TE,.PUT..Access- > 0x00d0: 436f 6e74 726f 6c2d 416c 6c6f 772d 4865 Control-Allow-He > 0x00e0: 6164 6572 733a 2043 6f6e 7465 6e74 2d54 aders:.Content-T > 0x00f0: 7970 650d 0a43 6f6e 7465 6e74 2d4c 656e ype..Content-Len > 0x0100: 6774 683a 2030 0d0a 5365 7276 6572 3a20 gth:.0..Server:. > 0x0110: 4a65 7474 7928 392e 332e 3236 2e76 3230 Jetty(9.3.26.v20 > 0x0120: 3139 3034 3033 290d 0a0d 0a 190403).... > > Interestingly, I see a “PUSH” flag set on the “PUT” packet and I don’t > even see the rest of the body in another packet this time, so that suggests > the difference is not just 1 vs. 2 packets but some other issue generating > a properly formatted body (although it could also be the server dropping > the connection before the client gets around to sending it). Note, though, > that the header has “Content-Length:19” which is exactly what I would > expect for the length of a properly formatted “{“host-id”:"goofy”}” packet ? > > FWIW I don’t get as far as a NPE - I have some logging that logs when a > null pointer comes in to the server stub and it decides to reject the call > with 400 error (“BAD REQUEST”) so I’m 100% sure my stub is, in fact, being > called with a null pointer for the body parameter, whereas with Postman it > works as expected, comes in with a non-null pointer, and sees what it > expects to see in the body parameter and completes normally. > > > I appreciate the point-out on “supportedPackagings", though - I’ll let you > know when I get a chance to work my way up to 9.4.x. > > Thanks, > -Patrick. > > On Apr 21, 2019, at 4:45 PM, Olivier Lamy <[email protected]> wrote: > > > Hi Patrick, > see inline. > On Sun, Apr 21, 2019 at 5:14 PM Patrick Dirks <[email protected]> wrote: > >> Hi Joakim, >> >> On Apr 20, 2019, at 9:36 PM, Joakim Erdfelt <[email protected]> wrote: >> >> 9.2.9 is rather old, even for the EOL 9.2.x series. >> Consider using 9.2.28.v20190418. >> Or if you want latest stable release, use 9.4.17.v20190418 >> >> >> Yes, I just noticed on the Jetty web site that 9.2.x was, in fact, EOL. >> I’m not sure how my system ended up with 9.2.9 installed - I believe that >> was hard-wired in the generated SwaggerHub server stubs. >> >> I’m not sure what incompatibilities I should look out for upgrading to >> 9.4.x. Offhand, just changing “jetty-version” in the generated pom.xml to >> 9.4.17.v20190418 makes “man clean package jetty:run” yields a complaint >> about the “.jar” format swagger-jaxrs-server that gets built not being >> supported: >> >> [INFO] <<< jetty-maven-plugin:9.4.17.v20190418:run (default-cli) < >> test-compile @ swagger-jaxrs-server <<< >> [INFO] >> [INFO] >> >> [INFO] --- jetty-maven-plugin:9.4.17.v20190418:run (default-cli) @ >> swagger-jaxrs-server --- >> [INFO] Logging initialized @6783ms to org.eclipse.jetty.util.log.Slf4jLog >> [INFO] Skipping swagger-jaxrs-server : packaging type [jar] is unsupported >> >> [INFO] >> ------------------------------------------------------------------------ >> [INFO] BUILD SUCCESS >> >> [INFO] >> ------------------------------------------------------------------------ >> [INFO] Total time: 5.980 s >> [INFO] Finished at: 2019-04-20T23:57:41-07:00 >> [INFO] ———————————————————————————————————— >> >> >> which wasn’t exactly what I was hoping for :-) >> > > That's something new in 9.4.x ( > https://github.com/eclipse/jetty.project/issues/2372 > <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Feclipse%2Fjetty.project%2Fissues%2F2372&data=02%7C01%7Cpdirks%40vmware.com%7C75e9c6c1780d439565b508d6c6b38588%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636914871692443189&sdata=C3fX0ptHZ6C4C9Wv0GQ8hxGK7qOpUrNu%2BGFWoYIT6z0%3D&reserved=0> > ) > You must add this jetty-maven-plugin configuration: > <supportedPackagings> > <supportedPackaging>jar</supportedPackaging> > </supportedPackagings> > > HTH > Olivier > >> >> >> OTOH, looking back through the Jetty releases I tried the MUCH more >> recent 9.3.26.v20190403 and THAT seems to suddenly work as expected! Looks >> like this may have been an issue cleaned up since 9.2.9 hit the streets! >> >> I think I’m good with 9.3.26.v20190403! I’ll test some other client >> stubs and see if this actually completely resolved the problem but it >> certainly appears to have fixes this issue. >> >> Thanks for the tip! >> >> Regards, >> -Patrick. >> >> >> Joakim Erdfelt / [email protected] >> >> >> On Sat, Apr 20, 2019 at 7:13 PM Patrick Dirks <[email protected]> wrote: >> >>> Hi, >>> >>> I’m new to Jetty - I'm experimenting with an API on SwaggerHub and I've >>> generated both client-side (cpprest) and server-side (JAX-RS) stubs from >>> the API. My server side is running jetty-9.2.9.v20150224. >>> >>> When I use a client like Postman, which sends the complete request >>> (headers and body) in a single packet, the server responds as expected. >>> When I use the generated (cpprest) client stubs the request headers come in >>> a first packet and the body in a second packet. The strange part is that, >>> although they re-assemble fine (I can see a valid-looking combined packet >>> in Wireshark), it looks as if the server request is dispatched as soon as >>> the headers arrive, without waiting for the body parameters to arrive >>> (despite the "Content-length" header value)? >>> >>> As a result the server sees a request that's got a "null" value for the >>> body parameter (even though the parameter is marked as "required"), as if >>> "delayDispatchUntilContent" is false? I've tried adding a "jetty.xml" file >>> that explicitly defaults and sets "delayDispatchUntilContent" to "true" but >>> that doesn't seem to make any difference. Neither does Swagger 2.0 vs. >>> OpenAPI 3.0 use make any difference. >>> >>> Any idea what I'm missing here? Any suggestions for a workaround, or a >>> fix? >>> >>> Thanks in advance! >>> -Patrick. >>> _______________________________________________ >>> jetty-users mailing list >>> [email protected] >>> To change your delivery options, retrieve your password, or unsubscribe >>> from this list, visit >>> https://www.eclipse.org/mailman/listinfo/jetty-users >>> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.eclipse.org%2Fmailman%2Flistinfo%2Fjetty-users&data=02%7C01%7Cpdirks%40vmware.com%7C75e9c6c1780d439565b508d6c6b38588%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636914871692453199&sdata=d8YgGd3VKeAJeagsxDHwR8GEp6%2F9DhpwP4PFJg0Rtfk%3D&reserved=0> >> >> _______________________________________________ >> jetty-users mailing list >> [email protected] >> To change your delivery options, retrieve your password, or unsubscribe >> from this list, visit >> >> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.eclipse.org%2Fmailman%2Flistinfo%2Fjetty-users&data=02%7C01%7Cpdirks%40vmware.com%7Ca7c9e4fef0184cdafd5708d6c612e60f%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636914181845701630&sdata=WxC5KN6%2B1I%2FvPWV001JcByKQ5DrV7PhcHcP5QeVrpOc%3D&reserved=0 >> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.eclipse.org%2Fmailman%2Flistinfo%2Fjetty-users&data=02%7C01%7Cpdirks%40vmware.com%7C75e9c6c1780d439565b508d6c6b38588%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636914871692453199&sdata=d8YgGd3VKeAJeagsxDHwR8GEp6%2F9DhpwP4PFJg0Rtfk%3D&reserved=0> >> >> >> _______________________________________________ >> jetty-users mailing list >> [email protected] >> To change your delivery options, retrieve your password, or unsubscribe >> from this list, visit >> https://www.eclipse.org/mailman/listinfo/jetty-users >> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.eclipse.org%2Fmailman%2Flistinfo%2Fjetty-users&data=02%7C01%7Cpdirks%40vmware.com%7C75e9c6c1780d439565b508d6c6b38588%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636914871692463203&sdata=5uiHSMmi28MYcveU9yU0R6pR4809jfGlFHK0gHgwuk8%3D&reserved=0> > > > > -- > Olivier > _______________________________________________ > jetty-users mailing list > [email protected] > To change your delivery options, retrieve your password, or unsubscribe > from this list, visit > > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.eclipse.org%2Fmailman%2Flistinfo%2Fjetty-users&data=02%7C01%7Cpdirks%40vmware.com%7C75e9c6c1780d439565b508d6c6b38588%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636914871692483218&sdata=GM%2B5nZ0qDgLw%2BLb2LEXkfSgKZTJ6s443v4hX%2BrJD1uM%3D&reserved=0 > > > _______________________________________________ > jetty-users mailing list > [email protected] > To change your delivery options, retrieve your password, or unsubscribe > from this list, visit > https://www.eclipse.org/mailman/listinfo/jetty-users
_______________________________________________ jetty-users mailing list [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users
