* * *

Author Topic: Webservice with TTCPBlockSocket  (Read 3115 times)

SymbolicFrank

  • Sr. Member
  • ****
  • Posts: 394
Re: Webservice with TTCPBlockSocket
« Reply #15 on: February 14, 2018, 07:25:24 pm »
How does a http message actually looks like?

Code: Pascal  [Select]
  1. Header1: Value1
  2. Header2: Value2
  3. Header3: Value3
  4.  
  5. This is the message, it can contain just about any legal UTF-8 char.
  6. And line breaks, of course.
  7. Note the empty line above the message, that's how you know where it starts.
  8.  

And this is what you receive. Everything else is a question of formatting. And the JSON would be the message, or inside <html><head/><body>JSON</body></html> tags, depending.

Renat.Su

  • Jr. Member
  • **
  • Posts: 91
    • Renat.Su
Re: Webservice with TTCPBlockSocket
« Reply #16 on: February 14, 2018, 07:27:04 pm »
TFPHTTPServer (fcl-web), synapse, BrookFramework
Quote
any HTTP component which I could build a webservice or anything like that? I mean "easier" to work with HTTP requests?

zyzmo

  • New member
  • *
  • Posts: 39
    • My Website
Re: Webservice with TTCPBlockSocket
« Reply #17 on: February 14, 2018, 08:03:45 pm »
How does a http message actually looks like?
[...]
And this is what you receive. Everything else is a question of formatting. And the JSON would be the message, or inside <html><head/><body>JSON</body></html> tags, depending.

I already found the resolution with rvk orientation! It was like TTCPBlockSocket don't accept "content-type: application/json" so I replaced it to "content-type: text/plain" and worked as expected!

Thanks for answer! 
<!-- Requirement Engineer -->

rvk

  • Hero Member
  • *****
  • Posts: 3468
Re: Webservice with TTCPBlockSocket
« Reply #18 on: February 14, 2018, 08:07:36 pm »
Well, it's  my first experience with this kind of function using Laz/FPC, and that was the way that I found to solve the problem! Probably there is an easiest way to do it...
Well, the problem lied on the client side. Angular (or the browser) first sends an OPTION request before sending the real GET or POST. That's because you added the custom headers. If you didn't, or you change the content-type, the GET or POST is sent directly. That's why it would also be an option to send an OK back to the client and wait for the actual GET or POST. It's really annoying that extra OPTION request is sent, but I don't know how to disable it easily, other than sending text/plain as content-type.

Quote
Do you know any HTTP component which I could build a webservice or anything like that? I mean "easier" to work with HTTP requests?
Synapse does not have such HTTP-server component. Indy does. But I'm not sure if Indy takes these pre-flight OPTION requests into account.

The best option would be to respons to the OPTION request with a HTTP/1.1 200 OK. After that you would get the actual GET. Then you're "server" would behave like it should.

Using text/plain will work fine too if you are sure the client always uses that.

rvk

  • Hero Member
  • *****
  • Posts: 3468
Re: Webservice with TTCPBlockSocket
« Reply #19 on: February 14, 2018, 08:33:27 pm »
F.Y.I. here is some information how you would respond to an OPTION request:
https://developer.mozilla.org/en-US/docs/Glossary/Preflight_request

zyzmo

  • New member
  • *
  • Posts: 39
    • My Website
Re: Webservice with TTCPBlockSocket
« Reply #20 on: February 14, 2018, 09:30:51 pm »
F.Y.I. here is some information how you would respond to an OPTION request:
https://developer.mozilla.org/en-US/docs/Glossary/Preflight_request
I'll read it!

Thanks!
<!-- Requirement Engineer -->

 

Recent

Get Lazarus at SourceForge.net. Fast, secure and Free Open Source software downloads Open Hub project report for Lazarus