These are chat archives for IndySockets/Indy

17th
Nov 2016
Walter Prins
@ByteJuggler
Nov 17 2016 12:38

With apologies in advance for the lengthy post, I'm hoping someone more immediately familiar with the ins and outs of Indy and how its used by Datasnap can point me in the right direction.

I'm trying to make a Datasnap server serve a file with RESUME support. Just making it serve a file is relatively trivial obviously, just add a TDSHttpServiceFileDispatcher component and attach to the TDSHTTPService. However the default service does not appear to support "RESUME" as pausing and resuming a download with (for example) the "DownThemAll" Firefox downloader in fact restarts the download.

In this context, I've found the following post by Remy on SO: http://stackoverflow.com/questions/21494524/indy-http-server-with-resume-support which implies that, at least for Indy, this is the default behaviour and that to support RESUME one has to intercept the GET request and interpose a TIdHTTPRangeStream object if ARequestInfo.Ranges.Count > 0.

Now as Datasnap is based internally on Indy, I'm hoping that I might apply the same approach but it's not entirely clear what the most appropriate place to do so is, as Datasnap abstracts away Indy as an implementation detail in many places and as a result the Indy "Ranges" property is not always available. when you seemingly want/need it.

Based on tracing the Datasnap code my current plan was to patch unit Datasnap.DSHTTP, method TIndyDispatchFileRequest.SetContentStream(AStream: TStream) on line 1555 to essentially do as suggested in the SO post. However the FRRequestInfo object present inside TIndyDispatchFileRequest at that point is not in fact the TIdHTTPRequestObject (that has a Ranges member), and it's not immediately obvious how one might get at it, so I'm wondering whether this is fundamentally perhaps the wrong place/way to tackle this problem.

Question: What is the right approach to tackle this problem? (One other thought I had was to patch IdCustomHTTPServer.DoCommandGet to interrogate the ARequestInfo and AResponseInfo after calling FOnCommandGet...)

(To add: Eventually I'd like to implement a file download using resume support in a Delphi client, as outlined in the following SO question: http://stackoverflow.com/questions/2963246/download-pause-and-resume-an-download-using-indy-components)

Walter Prins
@ByteJuggler
Nov 17 2016 12:46
(Using Delphi 10 Seattle)
Remy Lebeau
@rlebeau
Nov 17 2016 17:55
@ByteJuggler DataSnap may use Indy internally, but it is not based on Indy. In fact, in recent Delphi versions, Embarcadero has been slowly moving away from Indy in their technologies, like DataSnap, towards their own custom platform-native solutions. That being said, I don't know or use DataSnap, so I could be missing something, but since Indy is being used behind an abstraction layer, I don't see a way to get direct access to Indy's Request/Response objects from DataSnap's wrappers.
Remy Lebeau
@rlebeau
Nov 17 2016 18:05
@ByteJuggler looking into it deeper, I just now found that DataSnap's TDSHTTPResponseIndy class has a public ResponseInfo property that is an IPPeerAPI.IIPHTTPResponseInfo interface, which has a public GetObject() method. DataSnap's IPPeerServer.TIdHTTPResponseInfoPeer class implements IIPHTTPResponseInfo, where its GetObject() implementation returns Indy's TIdHTTPResponseInfo object from TIdHTTPServer. But TIdHTTPResponseInfoPeer is a private class in the IPPeerServer unit's implementation section, so you can't access it. But if you manually declare an equivilent class in your own code, you might get away with a type-cast hack to access the Indy object.