Wo Programmupdate hinspeichern

[freimatz]

Hoi,
Danke für die vielen Rückmeldungen. Insgesammt sehe ich das als recht aufwendig an wenn ich das ordentlich machen möchte. Als kurzfristige "Lösung" mache ich eine kleine Prüfung der Datei und gebe nun ggf. eine Fehlermeldung mit URL aus. Dann mag der Anwender selber schauen wie er die Setup-Datei auf seinen Rechner bekommt. (Ist sowieso eher ein exotisches Problem.)

@mensch72: Das erscheint mir als ein Ausnutzen einer Lücke der Firewall zu sein (genausso wie der Vorschlag des Testers die exe umzubennnen)

@Schokohase: Das wäre wohl die sauberste Lösung. Leider komme ich an den Header nicht ran. Derzeit verwende ich WinInet für das Laden. Ich dachte auch schon daran das auf Indy umzustellen das ich woanders auch schon benutze. Da wäre das einfacher.

@DieDolly: Ein Hash ist mir derzeit zu aufwendig. Würde bei diesem Problem auch nicht helfen.

Nochmals Danke an alle!
freimatz

[mensch72]

..."@mensch72: Das erscheint mir als ein Ausnutzen einer Lücke der Firewall zu sein (genausso wie der Vorschlag des Testers die exe umzubennnen)"...

- ja, einfach exe oder zip umbenennen umbenennen wäre nen typischer Test für Virentests... das müssen die erkennen und automatisch als Gefahr ausweisen.
Wenn so "Contentfilter" schon als LowLevelFirewall und gar auf exterener Hardware laufen, ist da was besseres am Start (Symantec bietet sowas z.B. Standalone auf Ent. Level)

- aber sagen wir die Anwendung Metadaten von Bilddateien(z.B. PNG&JPEG) mit "speziellen" Nutzinformationen zu versehen kommt aus der Apple-Offline-Welt!
Ohne installiertes ITunes funktioniert bei IPhones&IPads nur der Bilddatentransfer von/zu jedem per USB Kabel angeschlossenem "Fremdrechner".
Also mal fix ein Fehlerlog oder einen lokales Backup/Restore einer SQlite-DB ist für Ottonormal Apple Anwender sobald er in freier Wildbahn offline (oder gar Sibieren/Wüste/...) mal was austauschen oder empfangen soll schlicht auf ECHTE Bilddateien begrenzt(also auch da keine nur umbenannten ZIP/... Dateien!).

Das dies funktioniert ist Hersteller und Betriebssystem übergreifend so gewollt und hat nix mit einer Lücke z.B. in der Firewall zu tun
Prof. Kamerasysteme verstecken da spezielle Farbraumdaten oder bisherige Filtermatritzen, damit "nur die eigene Spezialsoftware" bei Weiterverarbeitung dies beachten kann.
Oder wegen Datenschutz müssen Backlinks in zu den Bilddaten besonders vor Fremdzugriff geschützt werden... also wenn in einem Bild 5Leute zu sehen sind und deren pers. Daten bekannt und verlinkt sind, dürfen diese Informationenn bei Weitergabe nicht offen für alle weiter verfügbar sein... weil da harte & gute Schutzalgos nun (hoffentlich) normal sind, kann sich kein aktiver Contentfilter daran stören, wenn eine Bilddatei voll nach Standard vorgesehene zusätzliche beliebige Metadaten inetgriert hat.

=> die Methode ist daher sowohl der sehr sicher, hoch kompatibel und vor allem sehr Endanwender freundlich, denn Fotos vom/zum Smartphone via Rechner... das ist aktuell hoch verbreitetes Basiswissen von jund bis alt


Wer für online wie offline verfügbar was vergleichbar einfaches und universelles hat, möge es mir bitte sagen.

[Schokohase]

An den Header kommt man sehr leicht heran, wenn man das richtig angeht. Hier mal ein kleines Beipiel, wie das prinzipiell gehen könnte:

Delphi-Quellcode:

uses
  Winapi.ShellAPI,
  Winapi.Windows,
  System.Classes,
  System.SysUtils,
  System.Net.HttpClient;

procedure DownloadFile( const AUrl: string; const AMimeType: string; const AStream: TStream );
var
  clt:      THttpCLient;
  response: IHTTPResponse;
begin
  clt := THttpCLient.Create( );
  try

    response := clt.Get( AUrl );
    if response.StatusCode = 200
    then
      begin
        if response.MimeType = AMimeType
        then
          begin
            AStream.CopyFrom( response.ContentStream, response.ContentLength );
          end else if response.MimeType.StartsWith( 'text/html', true )
        then
          begin
            ShellExecute( 0, 'open', PChar( AUrl ), nil, nil, SW_SHOW );
          end
        else
          raise Exception.CreateFmt( 'Unexpected Content-Type %s', [response.MimeType] );
      end
    else
      raise Exception.CreateFmt( 'Unexcepted StatusCode %d (%s)', [response.StatusCode, response.StatusText] );

  finally
    clt.Free( );
  end;
end;

procedure Main;
var
  stream: TMemoryStream;
begin
  stream := TMemoryStream.Create;
  try
    DownloadFile( 'https://www.delphipraxis.net/attachments/50203d1541379986-kodezwergs-tinihelper-klasse-inihelper.7z', 'application/x-7z-compressed', stream );
    WriteLn( stream.Size );
    stream.Clear( );
    DownloadFile( 'https://avm.de/fileadmin/user_upload/DE/Labor/Download/fritzbox-7590-labor-63282.zip', 'application/zip', stream );
    WriteLn( stream.Size );
    stream.Clear( );
  finally
    stream.Free;
  end;
end;

[Delphi.Narium]

Kann man für den Header nicht einfach response := clt.Head(AUrl); nehmen, damit kommt man den HTTP-üblichen Header, der alle Infos enthält.

Da steht dann drinne, welcher Mimetype geliefert wird, wie groß das Ergebnis sein wird, ob man auf 'ne andere Seite umgeleitet werden soll, welcher Responscode bei 'nem Get zu erwarten ist, ...

Also eigentlich alles, um anschließend gezielt weiterarbeiten zu können, sei es Download der gewünschten Datei oder eben Fehlerbehandlung, wenn die Datei nicht verfügbar ist.

Zitat von https://developer.mozilla.org/de/docs/Web/HTTP/Methods:

GET
The GET method requests a representation of the specified resource. Requests using GET should only retrieve data.
HEAD
The HEAD method asks for a response identical to that of a GET request, but without the response body.

https://tools.ietf.org/html/rfc7231#section-4.3.2

[Schokohase]

Zitat von Delphi.Narium:

Kann man für den Header nicht einfach response := clt.Head(AUrl); nehmen, damit kommt man den HTTP-üblichen Header, der alle Infos enthält.

Warum sollte man das nicht können?

[Delphi.Narium]

Wegen

Zitat von freimatz:

Leider komme ich an den Header nicht ran.

[freimatz]

Mit Betonung auf "ich" und für den Zeitpunkt von heute morgen. Hat sich ja nun gründlich geändert. Danke