Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 06:53
    iba-saw commented #447
  • 03:00
    rayaswdelphidev commented #321
  • 02:56
    rayaswdelphidev commented #343
  • 02:49
    rayaswdelphidev commented #321
  • Feb 01 17:42
    rlebeau commented #445
  • Feb 01 17:34
    rlebeau closed #446
  • Feb 01 17:34
    rlebeau commented #446
  • Feb 01 17:33
    rlebeau labeled #446
  • Feb 01 17:32
    rlebeau labeled #446
  • Feb 01 17:32
    rlebeau labeled #446
  • Feb 01 17:32
    rlebeau assigned #446
  • Feb 01 17:32

    rlebeau on Indy11-preparation

    Fixing a small typo in checkin … (compare)

  • Feb 01 17:30

    rlebeau on master

    Fixing a small typo in checkin … (compare)

  • Feb 01 17:23
    rlebeau commented #447
  • Feb 01 17:23

    rlebeau on Indy11-preparation

    Fixing some missing closing com… Removing GetLocalTime() from Id… Adding deprecated to IdServerIO… and 1 more (compare)

  • Feb 01 17:17
    rlebeau labeled #447
  • Feb 01 17:17
    rlebeau labeled #447
  • Feb 01 17:16

    rlebeau on master

    #447 Fixing compiler errors wit… (compare)

  • Feb 01 17:16
    rlebeau assigned #447
  • Feb 01 16:26
    rlebeau commented #445
Walter Prins
@ByteJuggler
@EricKing1 Fantastic. :)
Kudzu
@czhower
I wouldnt count on Indy past D7. Pre D7 there were some comiler features not available and its been years since I made changes to Indy, but at that time we did some things that did not jive with D6 compiler and decided ti was D7 forward at the time.
Remy Lebeau
@rlebeau
There are a lot of D5 and D6 users who use Indy, so I try to make sure Indy remains compatible with them. Recently, I encounted a nasty D5 bug that does not setup the call stack correctly when calling an overloaded class method that has an open array parameter, and that affects several of Indy's commonly used methods, like SendCmd(). The only workaround I have found so far is really ugly too, which is why I haven't checked it in yet. I'd hate to drop support for D5, though.
Kudzu
@czhower
Well if it works.. no need to drop it.
Remy Lebeau
@rlebeau
For the most part, Indy works fine in the old versions
EricKing1
@EricKing1
Indy 10 has been working great on my old D7. When loading the demos the changes in Indy 10 are updating the demo app. The only demo I am having an issue with is the Chat 2 demo. The idTCPServer and idTCPClient have changed dramatically since Indy 9. Would it be possible for one you delphi pros to take a look at it and update it. It's been a long time since I worked with delphi (I feel like I've been in hibernation for 10 years) . I wish I could update my delphi but D7 will have to work for now.
EricKing1
@EricKing1
This is amazing.... After 20 years the indy package still works great. Kudos Kudzu and all who are assisting. I am beginning to see the possibilities... Wow, a cell phone with a server who would guess this would ever happen....
Ludwig Behm
@lbehm
a cell phone with a server who would guess this would ever happen....
that sounds really scary....
Matthijs ter Woord
@mterwoord
the app needs permissoins for that, and i wouldn't give it those.....
EricKing1
@EricKing1
LOL - I didn't think I would get a response like that.. You are the developer and can dictate what ever your app does and does not . We are currently using all kinds of apps that are connecting to a server which records everything we type and even our current location. If you were able to wrote an app that would directly connect you to another user then a private chat would actually be private. (no outside server). Just thinking outside the box that we currently live in....
Kudzu
@czhower
Thanks. Remy though is largely the one carrying the torch into phones etc... I believe its mostly his efforts that got us there.
Jeroen Wiert Pluimers
@jpluimers
Shouldn't TIdURI.GetFullURI escape : and @ in usernames/passwords ?
Matthijs ter Woord
@mterwoord
@jpluimers Hi! :)
Kudzu
@czhower
@ is legit in URLs becuase of auto login
so it would have no way to encode it without complicated parsing.
Matthijs ter Woord
@mterwoord
does TIdURI let you specify a .Username and a.Password string?
Kudzu
@czhower
same for : IIRC but would have to lok at spec
dont remember.. if they are separated out, then yes it should escape htem.
Matthijs ter Woord
@mterwoord
last time i looked at delphi was today (fighting ole container, and stupid dev mistakes), last time before, no clue.. :)
this is interesting: c# doesn't do that..
var xUrl = new UriBuilder();
xUrl.Host = "localhost";
xUrl.UserName = "mterwoord@github.com";
xUrl.Password = "Pass:!@";

// xUrl.ToString() -> http://mterwoord@github.com:Pass:!@@localhost/
not trying to say that indy should match .net behavior per se, but worth investigating why that is...
(imo)
Ludwig Behm
@lbehm
@czhower I think @jpluimers means @ in the username part of an uri - which should be escaped.
Jeroen Wiert Pluimers
@jpluimers
I tried finding RFC info on this but my Google foo isn't helping much. There are some SO posts indicating %-hex escape but they don't make references to standards.
Matthijs ter Woord
@mterwoord
you saw RFC 1738?
and maybe 2141 or 2396
Jeroen Wiert Pluimers
@jpluimers
Indeed: https://tools.ietf.org/html/rfc1738#section-3.1 indicates @ : / need escaping.
Kudzu
@czhower
yes tehy do
@rlebeau
Jeroen Wiert Pluimers
@jpluimers
Which means .net is doing it wrong (:
Ludwig Behm
@lbehm
@jpluimers: https://tools.ietf.org/html/rfc3986#section-3.2.1 allows only userinfo = *( unreserved / pct-encoded / sub-delims / ":" ) which excludes @
Jeroen Wiert Pluimers
@jpluimers
@devimplode oh nice: conflicting info (:
Ludwig Behm
@lbehm
@jpluimers why?
Jeroen Wiert Pluimers
@jpluimers
@devimplode disregard, I was sleeping while reading. Not a good combination (:
Remy Lebeau
@rlebeau
The official syntax for URLs, which other formats are a subset of, is RFC 3986. Note that TIdURI is very old and doesn't follow very many parsing/encoding rules at all and was never RFC compliant. There are a lot of things it doesn't handle right. I have a replacement in works (TIdIRI) that implements RFC 3987, with descendants for scheme-specific RFCs, and will obsolute TIdURI.
Jeroen Wiert Pluimers
@jpluimers
Great! Let me know when there is something testable.
marbles99
@marbles99
Hi. Hope someone might be able to help me out here. Having a bit of an issue with connecting to an API of our webstore platform (ECWID). For legacy reasons, I am afraid I am still using INDY9 on D2007 (it's a grid component that is not available passed D2007 that holds us back a little). Anyway, we use HTTP/SSL to connect and process through the API. On Oct 11th this stopped working for no reason our end. Nothing changed here for a few months with this software so I know it was not here. Eventually, ECWID developer support admitted the had disabled an unsafe cipher on Oct 11th, so that matched up. They renabled it and the software worked again. But they disabled it immediately as they say it is unsafe. But it breaks our software. I thought it might be just a case of updating the SSL libraries. But the latest ones won't seem to load with Indy 9. The latest I can get to load still will not connect. Is there anything I can do to get this working? Any suggestions? I know ideally, Indy 10 might be the answer but in this instance it is just not possible.
This message was deleted
My other thought was to create a processor utility in Seattle/Indy10 (which I have at work) or Berlin/Indy10 (which I have at home). But I can't get this to work either. A very simple program just to use HTTP/SSL and a simple GET. Using the lastest SSL libraries (from Fulgan) just keeps coming up with an error (see below). I don't really want to go down this route though, I would rather be able to get the original programme working with calls within rather than have to call an external 'processor'.
marbles99
@marbles99
blob
Indy 9 version I am using which won't connect to the shop is 9.0.50 and Seattle version which erros as above is 10.6.2.5298
Ludwig Behm
@lbehm
Which ciphers and tls protocols does the API support?
marbles99
@marbles99
So they have told me, this is the cipher list: ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256
TLS1 and above
Thanks.
marbles99
@marbles99
I suspect this might be an SSL issue. I have tried creating a Synapse version of the call and on an older SSL it failed. Using the lastest, it worked. So guess the dilemma looks like not being able to use a later version of SSL that is compatible with the API ciphers in Indy 9. It may be I have to abandon Indy for this project and revert to Synapse if there is not an easy fix, which I suspect it isn't.
Remy Lebeau
@rlebeau
Indy 9 uses customized versions of the OpenSSL DLLs and thus cannot utilize newer OpenSSL versions. You need Indy 10 for that. Indy 9 does support TLS 1.0, though, so I would think turning off 1 cipher would not break as long as the other ciphers are available. If you use a packet sniffer like Wireshark, you can see the cipher list that your app's version of OpenSSL is offering to the server during the handshake.