Adding content type header as application/x-www-form-urlencoded #966

Activity

1. SaiKoganti05 commented on May 8, 2020

   

   SaiKoganti05

   on May 8, 2020

   Author

   More actions

   ApacheHttpClient.java
   Linenumber:86

   if (!headers.containsKey(CONTENT_TYPE)) {
   builder.addHeader(CONTENT_TYPE, DEFAULT_CONTENT_TYPE);
   }
2. kullfar commented on Dec 4, 2020

   

   kullfar

   on Dec 4, 2020

   Member

   More actions

   Hi!
   I will use data from the RFC 7231 Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
   https://tools.ietf.org/html/rfc7231

   It states

   A payload within a DELETE request message has no defined semantics;
      sending a payload body on a DELETE request might cause some existing
      implementations to reject the request.
   

   © https://tools.ietf.org/html/rfc7231#section-4.3.5

   So, RFC does NOT FORBID payload in the DELETE request. And by fact, some implementations use payload in such requests. So, ScribeJava let's them work, being flexible library to use in any circumstances.

   Next, chapter about Content-type header (https://tools.ietf.org/html/rfc7231#section-3.1.1.5) doesn't require to not send this header in case of empty payload. And in practice, some servers can ignore requests without this header. So, again, let's be flexible and if it doesn't conflict with the RFC let it be possible to use. I suppose some servers can (and actually should) use this header before accessing payload (and realising, that it's empty. It depends on their implementations).

      In practice, resource owners do not always properly configure their
      origin server to provide the correct Content-Type for a given
      representation, with the result that some clients will examine a
      payload's content and override the specified type.  Clients that do
      so risk drawing incorrect conclusions, which might expose additional
      security risks (e.g., "privilege escalation").  Furthermore, it is
      impossible to determine the sender's intent by examining the data
      format: many data formats match multiple media types that differ only
      in processing semantics.  Implementers are encouraged to provide a
      means of disabling such "content sniffing" when it is used.
   

   © https://tools.ietf.org/html/rfc7231#section-3.1.1.5

   And some servers do this in case of empty payloads as well. Ok, why not? Sometimes it makes sense. Imagine, that you want to know how to interpret empty payload, as xml, or as json? ;-)

   And the finally, ScribeJava is not a fundamental theoretical implementation of RFCs, it is supposed to be the library to use in practical way, so it will allow any usage to make the job done and will contain minimum of requirements and blockers, that can break any integration because of not well written servers.

   I hope, I have answered you.
3. kullfar

   closed this as completedon Jan 14, 2021