TIDHttpServer ... RequestInfo.PostStream = nil

[GuenterS]

Hallo,

ich versuche gerade mit der HttpServer Komponente der Indy Komponenten, mir einen brachialen WebServer zu schreiben. Im Commandget Ereignis versuche ich die Eigenschaft PostStream von ARequestInfo auszuwerten, jedoch ist die immer nil.

Delphi-Quellcode:

procedure TJDFServer.HttpSrvCommandGet(AThread: TIdPeerThread;
  ARequestInfo: TIdHTTPRequestInfo; AResponseInfo: TIdHTTPResponseInfo);
var

  lFileStream: TFileStream;
begin
  lFilestream := TFileStream.Create('c:\temp\log.txt', fmCreate);
  try
     lFileStream.CopyFrom(ARequestInfo.PostStream, ARequestInfo.PostStream.Size);          
  finally
     FreeAndNil(lFileStream);
  end;
end;

Es kracht aber jedesmal da ARequestInfo.PostStream nicht zugewiesen ist.

Kann mir jemand sagen, wie man sonst an die entsprechenden Daten kommt?

[SvB]

Benutzt Du die integrierte Version der Indy Komponenten. Falls ja, ist es vielleicht sinnvoll die aktuellste Version herunterzuladen un zu installieren.
Die Version, die z.B. bei D2007 oder RAD 2007 enthalten ist, war auch schon bei D2006 dabei und das ist schon eine ziemlich alter Version.
Eventuell ist in der aktuellen Version der Indy auch ein Rückgabewert <> nil dabei.
Mehr kann ich im Moment auch nicht dazu sagen.

Grüße Sven

[marabu]

Hallo Günter,

der Server hat eine property OnCreatePostStream, der du einen eigenen event handler zuweisen kannst. Wenn du dort den PostStream bereit stellst, dann weißt du auch, wie du an die Daten kommst. Ansonsten wird der Ordnung halber intern ein StringStream erzeugt, aber an den kommst du nicht heran.

Freundliche Grüße

[GuenterS]

Ich verwende die Version die bei Delphi7 Enterprise dabei ist.


Das mit dem OnCreatePostStream-Event hat funktioniert.


Vielen Dank :-)

Hat es irgendeinen Grund warum das so implementiert wurde, dass man nicht an den internen StringStream herankommt?

[marabu]

Zitat:

Zitat von GuenterS

... Hat es irgendeinen Grund warum das so implementiert wurde, dass man nicht an den internen StringStream herankommt? ...

Ich bin nicht Architekt im INDY-Projekt, aber ich hätte es auch so gemacht: Auf diese Weise kann der Entwickler die Art des Streams frei wählen, z.B. TFileStream oder TMemoryStream.

[Dani]

Zitat:

Hat es irgendeinen Grund warum das so implementiert wurde, dass man nicht an den internen StringStream herankommt?

Eigentlich dürfte der PostStream niemals nil sein :gruebel:

Delphi-Quellcode:

{
  Rev 1.42    3/14/05 11:45:50 AM  RLebeau
  Buf fix for DoExecute() not not filling in the TIdHTTPRequestInfo.FormParams
  correctly.

  Removed LImplicitPostStream variable from DoExecute(), no longer used.
  TIdHTTPRequestInfo takes ownership of the PostStream anyway, so no need to
  free it early.  This also allows the PostStream to always be available in the
  OnCommand... event handlers.
}

...

              // Grab Params so we can parse them
              // POSTed data - may exist with GETs also. With GETs, the action
              // params from the form element will be posted
              // TODO: Rune this is the area that needs fixed. Ive hacked it for now
              // Get data can exists with POSTs, but can POST data exist with GETs?
              // If only the first, the solution is easy. If both - need more
              // investigation.

              // i := StrToIntDef(LRequestInfo.Headers.Values['Content-Length'], -1);    {Do not Localize}
              LRequestInfo.PostStream := nil;
              CreatePostStream(AContext, LRequestInfo.RawHeaders, LRequestInfo.FPostStream);
              if LRequestInfo.FPostStream = nil then begin
                LRequestInfo.FPostStream := TMemoryStream.Create;    {Do not Localize}
              end;

Zitat:

Ich verwende die Version die bei Delphi7 Enterprise dabei ist.

Wer lesen kann... (ich = Idiot) :(

[marabu]

Hallo Dani,

du hast die falsche (zu neue) Quelle angeschaut. Die bei D7 mitgelieferte (und von Günter benutzte) Version 9 der Indy-Komponenten ist deutlich älter als März 2005.

Freundliche Grüße

[GuenterS]

Das ist ja eh toll, aber warum ist der StringStream nicht zugänglich? Man hätte den Inhalt ja an einen Stream seiner Wahl kopieren können.

Ok, das hat sich ja wie Dani schreibt, ja eh gelöst mit neueren Versionen.

@Dani
Wer lesen kann ... herzlichen Dank ... vielleicht selber mal beherzigen.

[Dani]

Zitat:

Zitat von GuenterS

@Dani
Wer lesen kann ... herzlichen Dank ... vielleicht selber mal beherzigen.

Öhm, das ging an mich selbst! Ich habe doch überlesen, dass du die mitgelieferte Version verwendest :cheers:

[GuenterS]

Zitat:

Zitat von Dani

Zitat:

Zitat von GuenterS

@Dani
Wer lesen kann ... herzlichen Dank ... vielleicht selber mal beherzigen.

Öhm, das ging an mich selbst! Ich habe doch überlesen, dass du die mitgelieferte Version verwendest :cheers:

Ok, tschuldigung... das kam nicht so ganz heraus, bevor du es editiert hast ... ich idiot ist aber übertrieben ... kann ja wohl passieren, wer weiß schon alle Versionen auswendindig...

[marabu]

Hallo Günter,

Zitat:

Zitat von GuenterS

... aber warum ist der StringStream nicht zugänglich? Man hätte den Inhalt ja an einen Stream seiner Wahl kopieren können. ...

das Konzept ist einfach: Entweder der PostStream ist unter der Kontrolle deines Programms oder unter der Kontrolle der Komponente. Die Erzeugung durch die Komponente und die Freigabe durch dein Programm (mixed responsibilities) ist kein so toller Ansatz und wird deshalb nicht so gerne implementiert. Der interne PostStream wird also nur solange am Leben erhalten, wie notwendig. Sein Inhalt wird für dich in RequestInfo.FormParams als String abgelegt.

Freundliche Grüße

[GuenterS]

ok, damit hätte ich meine Aufgabe auch lösen können, wollte nämlich nur abspeichern was da so ankommt, auf einer bestimmten Adresse.