Recent

Author Topic: [SOLVED] HTTP GET + REQUEST BODY  (Read 2879 times)

Warfley

  • Hero Member
  • *****
  • Posts: 814
Re: [SOLVED] HTTP GET + REQUEST BODY
« Reply #15 on: January 29, 2022, 11:37:43 am »
And finally the question:

Is it ok and supported that I do a HTTP GET operation sending also a REQUEST BODY?
Is it possible to receive such a REQUEST BODY, parse it and use it as I described?

I read many things telling me that GET should be used only to get objects identified
only using the URI, and including the REQUEST BODY it against this recommendation.

So far I have been using fphttpapp on server side, and fphttpclient on client side...

If is not possible or recommended does anyone have some alternative advice?

THANK YOU!!!
To giva a real answer to these questions, the HTTP/1.1 Specification RFC7231 states in Section 4.3.1
Quote
   A payload within a GET request message has no defined semantics;
   sending a payload body on a GET request might cause some existing
   implementations to reject the request.
It is so called undefined behavior. Implementing it is not wrong, but you can not expect the other side to also implement it. In fact many Client and Server libraries do not implement this. From personal experience I can say that the the HTTP Server and HTTP Client provided by Java standard library for example does not provide this functionality.
Long story short you should not use this.

That said, you can still transfer information via an HTTP GET request, as part of the URI, either as query (the stuff in a URI after the ?), or as Fragment (the stuff in the URI after the #). And it is very common to sometimes transmit even largeer amounts of data via get, e.g. in SAML or OAuth the whole request is encoded as GET request, which can get up to a few Kilobytes in size.
The only problem here is that some server or browser implementations are not capable of handling such large URIs. While the HTTP Standard in RFC 7230 Section 3.1.1 recommends that all implementations should support at least 8kbytes, to support older browsers, it is usually recommended to not exceed 2 kbytes.

So while the general rule of thumb for requests is to use GET for receiving data and POST for sending data (as the names where chosen for this), you can also use GET to transmit data, and there are some advantages to that, mainly that you can encode and alter the data within 403 redirects, something that is not allowed for POST data (which is either lost on 301, 302 or 303, or the data must be sent unchanged as per 307 and 308), which is why it is for example used for OAuth or SAML as here redirects are often common.

Long story short, you can send data via GET, and it is sometimes useful, but you should not send it as body bot encode it either as Query and/or Fragment

tt

  • Jr. Member
  • **
  • Posts: 63
Re: [SOLVED] HTTP GET + REQUEST BODY
« Reply #16 on: January 31, 2022, 08:40:33 am »
Some open source network-capable offshoots of SQLite which may suit your use case and could minimize custom programming on your part:

Thank you very much for these suggestions.

tt

  • Jr. Member
  • **
  • Posts: 63
Re: [SOLVED] HTTP GET + REQUEST BODY
« Reply #17 on: January 31, 2022, 09:05:00 am »
And finally the question:

Is it ok and supported that I do a HTTP GET operation sending also a REQUEST BODY?
Is it possible to receive such a REQUEST BODY, parse it and use it as I described?

I read many things telling me that GET should be used only to get objects identified
only using the URI, and including the REQUEST BODY it against this recommendation.

So far I have been using fphttpapp on server side, and fphttpclient on client side...

If is not possible or recommended does anyone have some alternative advice?

THANK YOU!!!
To giva a real answer to these questions, the HTTP/1.1 Specification RFC7231 states in Section 4.3.1
Quote
   A payload within a GET request message has no defined semantics;
   sending a payload body on a GET request might cause some existing
   implementations to reject the request.
It is so called undefined behavior. Implementing it is not wrong, but you can not expect the other side to also implement it. In fact many Client and Server libraries do not implement this. From personal experience I can say that the the HTTP Server and HTTP Client provided by Java standard library for example does not provide this functionality.
Long story short you should not use this.

That said, you can still transfer information via an HTTP GET request, as part of the URI, either as query (the stuff in a URI after the ?), or as Fragment (the stuff in the URI after the #). And it is very common to sometimes transmit even largeer amounts of data via get, e.g. in SAML or OAuth the whole request is encoded as GET request, which can get up to a few Kilobytes in size.
The only problem here is that some server or browser implementations are not capable of handling such large URIs. While the HTTP Standard in RFC 7230 Section 3.1.1 recommends that all implementations should support at least 8kbytes, to support older browsers, it is usually recommended to not exceed 2 kbytes.

So while the general rule of thumb for requests is to use GET for receiving data and POST for sending data (as the names where chosen for this), you can also use GET to transmit data, and there are some advantages to that, mainly that you can encode and alter the data within 403 redirects, something that is not allowed for POST data (which is either lost on 301, 302 or 303, or the data must be sent unchanged as per 307 and 308), which is why it is for example used for OAuth or SAML as here redirects are often common.

Long story short, you can send data via GET, and it is sometimes useful, but you should not send it as body bot encode it either as Query and/or Fragment

Thank you very very very much for this detailed explanation.


 

TinyPortal © 2005-2018