While enabling NullAway for root org.asynchttpclient package, I noticed that DefaultRequest#getQueryParams in case of query param with no value (i.e. http://example.com/request?abc) will create Param instance with the value set to null.
But OAuthSignatureCalculatorInstance#encodedParams doesn't check for null-values when calling percentEncodeAlreadyFormUrlEncoded() resulting in NullPointerException.
I didn't change the way Param instances are created because according to this SO answer RFC 3986 doesn't specify the structure of the query string, so technically speaking http://example.com/request?abc and http://example.com/request?abc= are different URLs.
Instead I added null-check to percentEncodeAlreadyFormUrlEncoded() method because RFC 5849 The OAuth 1.0 Protocolsays that query parameters should be treated the same way as application/x-www-form-urlencoded parameters as defined in HTML 4.0 Specification - a list of name=value pairs created from valid HTML elements (i.e. input, textarea, select, etc), and HTML elements input type="text" and textarea use an empty string instead of null values.
And I also tested this fix against http://lti.tools/oauth/ just in case, and both current implementation and that site produce the same result.
While enabling NullAway for root
org.asynchttpclientpackage, I noticed that DefaultRequest#getQueryParams in case of query param with no value (i.e.http://example.com/request?abc) will createParaminstance with the value set tonull.But
OAuthSignatureCalculatorInstance#encodedParamsdoesn't check for null-values when calling percentEncodeAlreadyFormUrlEncoded() resulting inNullPointerException.I didn't change the way
Paraminstances are created because according to this SO answer RFC 3986 doesn't specify the structure of the query string, so technically speakinghttp://example.com/request?abcandhttp://example.com/request?abc=are different URLs.Instead I added null-check to
percentEncodeAlreadyFormUrlEncoded()method because RFC 5849The OAuth 1.0 Protocolsays that query parameters should be treated the same way asapplication/x-www-form-urlencodedparameters as defined in HTML 4.0 Specification - a list ofname=valuepairs created from valid HTML elements (i.e.input,textarea,select, etc), and HTML elementsinput type="text"andtextareause an empty string instead of null values.And I also tested this fix against http://lti.tools/oauth/ just in case, and both current implementation and that site produce the same result.