Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 06:11
    grahamegrieve commented #299
  • 05:05
    grahamegrieve commented #299
  • 05:04
    grahamegrieve commented #299
  • Oct 24 18:58
    grahamegrieve commented #299
  • Oct 24 18:52
    grahamegrieve commented #299
  • Oct 24 18:50
    grahamegrieve commented #299
  • Oct 24 18:43
    grahamegrieve commented #299
  • Oct 24 18:39
    SlMaker commented #299
  • Oct 24 18:10
    grahamegrieve commented #299
  • Oct 24 17:34
    grahamegrieve commented #299
  • Oct 24 17:34
    grahamegrieve commented #299
  • Oct 24 09:50
    grahamegrieve commented #299
  • Oct 24 06:19
    grahamegrieve commented #299
  • Oct 24 06:12
    grahamegrieve commented #299
  • Oct 22 19:28
    rlebeau commented #326
  • Oct 22 00:30
    grahamegrieve synchronize #326
  • Oct 21 16:56
    rlebeau commented #6
  • Oct 21 08:22
    grahamegrieve opened #326
  • Oct 20 18:20
    rlebeau commented #297
  • Oct 20 18:12
    tothpaul closed #297
Paessler
@Paessler
Hi guys, do you know if there is any plan to upgrade indy for use with openSSL 1.1.0 Branch in the near future?
Remy Lebeau
@rlebeau
there is no immediate plan for that at this time. 1.1.0 introduces major API breakages over previous versions, I don't know what the level of effort will be yet to support the new API, especially in parallel with the earlier API.
1.1.0 was just officially released a few days ago, and 1.0.2 is not going away for several years. So there is time to migrate Indy to 1.1.0 eventually.
Paessler
@Paessler
yeah but browsing through all the API and Statemachine changes worries me a bit especially since we use a whole set of libraries depending on OpenSSL which is/was a fuzzle to keep in sync in the past. Thanks for your reply Remy
petesky
@petesky
Hi, http://indy.fulgan.com/SSL/ is not available anymore ?
Remy Lebeau
@rlebeau
It is still available, it just appears to be down right now. I have reported it.
Remy Lebeau
@rlebeau
It is working again
davidpn
@davidpn
@rlebeau Are you able to set up an IPv6 only network so you can verify that TIdHTTP can handle it? Alternatively, are you aware if it doesn't? This is for Indy 10 that comes with 10.1 Berlin.
Remy Lebeau
@rlebeau
@davidpn I have not verified it, and I am not aware of any issues that would prevent it from working.
davidpn
@davidpn
ok.. not sure if I can come up with steps for you.. you don't have a Mac, for example, yes?
Remy Lebeau
@rlebeau
I have a couple of OSX VMs, but I don't know if they have the option of creating an IPv6 network for testing. I'm trying to run one of them right now, but it is really slow
davidpn
@davidpn
perhaps if I detail where it breaks down.. I'm willing to spend a bit of time on it, because I'd prefer to keep using Indy, and right now at work it's a "must have" because we want to use TestFlight for external testing and I expect the app will be rejected if it fails IPv6 only. They're moving away from Indy after this prototype has lived out its life
Remy Lebeau
@rlebeau
my OSX VMs are too old. Creating an IPv6 network was added in El Capitan, but my VMs are Mountain Lion and Mavericks, which don't have the option.
davidpn
@davidpn
fair enough.. like I say, I'll look into it; more than likely before the end of the weekend. It has risen high on my to-do list
Wil32
@Wil32
i have a el capitan vm. you a wireless adapter to make the whole thing work. just follow apple's doc.
davidpn
@davidpn
I know how to make a IPv6 only network.. it's making TIdHTTP work with it that is the problem
I didn't get far over the weekend with diagnosing the problem, however my initial guess is that it simply doesn't switch to IPv6 if IPv4 doesn't work (or cannot detect IPv6 only)
Remy Lebeau
@rlebeau
Indy does not switch automatically, you have to tell it which IP version to use ahead of time. By default, everything it does uses IPv4 unless told otherwise. In IdCompilerDefines.inc, you can set the default to IPv6 instead (that is what Embarcadero did for their iOS bundled version of Indy). Alternatively, you would have to manually detect the network IP version and then configure Indy accordingly at runtime when making connections.
Since you mention TIdHTTP, I suspect it is treating your URLs as IPv4 unconditionally. For IPv6, you have to wrap hostnames in brackets, eg: http://[hostname]:port/resource. If you get an HTTP redirect to a different hostname, that might switch back to IPv4. I will have to check that.
davidpn
@davidpn
we also don't want to have to wrap all URLs
"Alternatively, you would have to manually detect the network IP version and then configure Indy accordingly at runtime when making connections" I had been attempting to work out how to do that..
I tested on the weekend with the Indy that is bundled with Delphi.. it doesn't default to IPv6
i.e. Delphi 10.1 Berlin
Remy Lebeau
@rlebeau
I know for a fact that Embarcadero's bundled version of Indy defaults to IPv6 on iOS, because I remember finding that Embarcadero had made that change without telling me when they shipped it. But either way, TIdHTTP is a special case because of the way it handles URLs internally, so it is probably ignoring any preexisting IP settings. I will have to double check that when I have some time. Other Indy components don't suffer from the issue since they don't handle URLs directly
davidpn
@davidpn
ok.. it makes sense if TIdHTTP behaves differently
I'll be looking further into it tonight (melbourne time)
davidpn
@davidpn
Look at lines 15 and 16 of IdCompilerDefines.inc in Delphi 10.1 Berlin Update 1, Indy10 source
Remy Lebeau
@rlebeau
I don't have Berlin installed yet. Been trying to, keep running into problems with it.
davidpn
@davidpn
can you then explain: "I remember finding that Embarcadero had made that change without telling me when they shipped it"?
Remy Lebeau
@rlebeau
Exactly what I said. They made changes to Indy (in this case, enabling IPv6 by default on iOS), shipped the change in a new IDE release (causing some DFM breakages in the process), and didn't tell me they had made the change, I found out later when problem reports started coming in. It is not the first time Embarcadero made changes to Indy and didn't tell me, though they are usually pretty good about sending patches to me instead so I can review them first. Looking back over my discussions with them, the IPv6 change was made during the 10.1 Berlin beta testing, so it might have been pulled out before the final release. They might be using the IPVersion property in their own code instead.
davidpn
@davidpn
ah, ok..
delphiunderground
@delphiunderground
Hi Remy, I need some BIO functions for this code : https://github.com/delphiunderground/eid-mw-sdk-delphi/blob/master/utils.pas
thank in advance
Remy Lebeau
@rlebeau
@delphiunderground committed
Ludwig Behm
@lbehm
Can someone explain me why TIdHTTPWebBrokerBridge wants to create a WebModul instance for each WebRequest? (or why Embarcadero wants multiple instances - I know WebReq can reuse them)
Are they not threadsafe or does Embarcadero just expects from the normal dev, that they implement them in an not-threadsafe manner?
From a performace point of view: Would you recommend to skip TIdHTTPWebBrokerBridge and handle Requests from OnCommandGet to a simplified TCustomWebDispatcher instance? In the end I want to serve multiple WebDispatcher. (REST, FileDispatcher)
Maicon Martins
@MRMartins666_twitter
good personal day, someone help me with a question about an SFTP connection using Indy 10?
good morning*
Maicon Martins
@MRMartins666_twitter
the connection is completed, however I can not access the folders
Failed to change directory.
Maicon Martins
@MRMartins666_twitter
using Delphi 2010
Walter Prins
@ByteJuggler
Hellooo!!!! Anybody home? :)
Walter Prins
@ByteJuggler
We've finally got around to upgrading from Seattle to Berlin 10.1 Update 1, however I'm getting strange problems with TIdHTTP on 10.1 against a particular web service. Code which worked fine on Seattle (and for many versions prior) is getting HTTP 403 rejections from a Squid NTLMSSPI proxy server. The same code and proxy server works with Seattle and succeeds with HTTP 200. Any suggestions? Unfortunately putting together a SSCCE for this may be challenging due to the involvement of the proxy server which may or may not be contributing in some way to the issue, as well as the particular web service being called. But again: The exact same code works fine via the same proxy server when compiled with Seattle, which suggests something has changed in 10.1 Berlin to cause this...
Remy Lebeau
@rlebeau
@devimplode I have no idea how WebBroker works or why it manages its objects the way it does.
@MRMartins666_twitter Indy does not support SFTP (FTP over SSH), but it does support FTPS (FTP over SSL). If you are sucessfully connected to an FTP(S) server and simply getting an error with the TIdFTP.ChangeDir() method, chances are your logged in user account does not have access to the folder you are trying to change to.
@ByteJuggler I am not aware of any changes in TIdHTTP between Seattle and Berlin that would account for what you are seeing. You are going to have to debug your code to see what is actually happening. For starters, I would suggest using a packet sniffer like Wireshark, or at least attach a TIdLog... component to TIdHTTP, to see if there are any differences between the HTTP requests that Seattle sends vs the HTTP requests that Berlin sends.
Walter Prins
@ByteJuggler
@rlebeau OK thanks I'll try TIdLog and perhaps try wireshark if need be... thanks for the response.
Ludwig Behm
@lbehm
thanks @rlebeau, I will just test it further... it's funny how the "performance" related blog posts I found yet, completely ignore how Indy and the WebBroker internals work...
Walter Prins
@ByteJuggler
@rlebeau It seems it's HTTPS related. I installed wireshark and changed the protocol to http to enable easy capture. Surprisingly the Berlin build then worked, and I confirmed that the underlying requests made by Berlin and Seattle were byte identical (over http, sans the obvious things like cookie values and datetimes and whatnot) by capturing the conversation and comparing/diffing. I've never stripped SSL with wireshark so now it's going to be trying to figure out why using https with Seattle works but using https with Berlin Indy does not. (Was there any SSL related changes between Seattle and Berlin?)
Walter Prins
@ByteJuggler
Actually, scratch that byte identical comment (i.r.o HTTP), not quite accurate. There are 1 difference perhaps worth noting -- The Seattle request has "Accept-Encoding: identity" which the Berlin is lacking... not sure what that does/means or whether it's relevant, but it's a difference.