Recent

Author Topic: Implementation question about TFPHTTPClient  (Read 2332 times)

Xor-el

  • Sr. Member
  • ****
  • Posts: 404
Implementation question about TFPHTTPClient
« on: February 19, 2019, 03:47:41 pm »
So I was reading about TFPHTTPClient today and discovered that to perform HTTPS requests, OpenSSL binaries has to be available on the host system.
So I wanted to ask if there is any reason FPC developers when designing TFPHTTPClient decided against following the Delphi pattern in System.net.HTTPClient of encapsulating each supported OS networking capabilities as Delphi did which will remove the dependency for OpenSSL binaries when performing HTTPS operations (at least for OSes that supports this)?

Xor-el

  • Sr. Member
  • ****
  • Posts: 404
Re: Implementation question about TFPHTTPClient
« Reply #1 on: February 20, 2019, 01:49:45 pm »
any updates please?  :(

lucamar

  • Hero Member
  • *****
  • Posts: 4219
Re: Implementation question about TFPHTTPClient
« Reply #2 on: February 20, 2019, 02:04:47 pm »
I'm not an FPC developer so I know nothng of their reasons but one fundamental difference between Delphi and FPC has always been the multi-platform nature of the later. Too achieve this it is usually useful to rely on multi-platform libraries and since the more widely used multi-platform SSL lib is OpenSSL ... well there you have it. It's something similar to the reliance on SDL/OpenGL for graphics/mutimedia--although not so marked with these.

Note also that both Indy and Synapse, the more used web libraries for Delphi, depend on OpenSSL too (or other even more esoteric libs in the case of Synapse), so there must be something going for it.
« Last Edit: February 20, 2019, 02:06:50 pm by lucamar »
Turbo Pascal 3 CP/M - Amstrad PCW 8256 (512 KB !!!) :P
Lazarus/FPC 2.0.8/3.0.4 & 2.0.12/3.2.0 - 32/64 bits on:
(K|L|X)Ubuntu 12..18, Windows XP, 7, 10 and various DOSes.

Xor-el

  • Sr. Member
  • ****
  • Posts: 404
Re: Implementation question about TFPHTTPClient
« Reply #3 on: February 20, 2019, 03:48:16 pm »
I'm not an FPC developer so I know nothng of their reasons but one fundamental difference between Delphi and FPC has always been the multi-platform nature of the later. Too achieve this it is usually useful to rely on multi-platform libraries and since the more widely used multi-platform SSL lib is OpenSSL ... well there you have it. It's something similar to the reliance on SDL/OpenGL for graphics/mutimedia--although not so marked with these.

Note also that both Indy and Synapse, the more used web libraries for Delphi, depend on OpenSSL too (or other even more esoteric libs in the case of Synapse), so there must be something going for it.

thanks for your answer.
while I understand that FPC supports far more platforms than Delphi, it is saddening that we have to depend on an external library (that cannot be statically linked as a single binary with our program),
it would have been better (at least in my own view) to encapsulate the native SSL capabilities of at least the most popular platforms like Windows, Mac OSX and Linux and use OpenSSL for other unpopular platforms.
But what do I know, am just a regular joe who loves and uses FPC because of its cross platform abilities without having to depend on external libraries (binaries).  :)
Waiting for other people's view on this though.

Quote
Note also that both Indy and Synapse, the more used web libraries for Delphi, depend on OpenSSL too (or other even more esoteric libs in the case of Synapse), so there must be something going for it.

Regarding this, I think it is more about taking the easy way out.  8)

Thanks once again.
« Last Edit: February 20, 2019, 03:55:30 pm by Xor-el »

Thaddy

  • Hero Member
  • *****
  • Posts: 14205
  • Probably until I exterminate Putin.
Re: Implementation question about TFPHTTPClient
« Reply #4 on: February 20, 2019, 03:56:36 pm »
@Xor-el
Although someone like you is perfectly capable to provide a native ssl solution, the problem would be that in secure applications one tends to follow and use standard implementations since these are better tested because of a vastly larger user base.
I wouldn't mind using your native implementation, but not in commercial applications because I fear maintenance and testing would be sub-standard (to the standard implementations).
This is also the reason why there are few of those: most software houses use something that they know is frequently and thoroughly tested. But why not show us a proof of concept? You have the expertise...and I already use some of your code elsewhere in production.. ;)

(Note - bad joke - such an implementation would satisfy security by obscurity... :D )
« Last Edit: February 20, 2019, 04:05:50 pm by Thaddy »
Specialize a type, not a var.

Xor-el

  • Sr. Member
  • ****
  • Posts: 404
Re: Implementation question about TFPHTTPClient
« Reply #5 on: February 20, 2019, 04:36:11 pm »
@Xor-el
Although someone like you is perfectly capable to provide a native ssl solution, the problem would be that in secure applications one tends to follow and use standard implementations since these are better tested because of a vastly larger user base.
I wouldn't mind using your native implementation, but not in commercial applications because I fear maintenance and testing would be sub-standard (to the standard implementations).
This is also the reason why there are few of those: most software houses use something that they know is frequently and thoroughly tested. But why not show us a proof of concept? You have the expertise...and I already use some of your code elsewhere in production.. ;)

(Note - bad joke - such an implementation would satisfy security by obscurity... :D )

@Thaddy, there is a lot of truth in your explanations, Thanks.
Also thanks for the kind words.

 

TinyPortal © 2005-2018