Hi,
»» wenn ich einen Request mit multipart/related content-type schicke
du meintest sicher einen Response. ;-)
Du darfst es mir durchaus zutrauen, den Unterschied zwischen Request und Response zu kennen.
Es geht tatsächlich um Requests.
Wie Du meinem Beispiel entnehmen konntest, geht es um soap. Und da hat durchaus auch mal der Request mehrere Teile.
Der start-Parameter ist optional, wie ich eben gelesen habe; wird er weggelassen, gilt "the first part" als Start.
Ja, aber. Die Gegenstelle braucht ihn.
»» Bei der boundary bin ich mir ziemlich sicher, daß ich bei mehreren derartigen Requests immer wieder dieselbe boundary verwenden darf (hier scheint der letzte Teil nach dem . ein timestamp zu sein - m.W. muß es aber nur ein String sein, der innerhalb des eigentlichen Content nicht vorkommt).
Innerhalb derselben Hierarchieebene *müssen* die Boundaries sogar gleich sein, deswegen werden sie ja im Header bekanntgegeben.
Es wird nur die zwei angedeuteten Teile geben. Also eh nichts mit mehreren Hierarchie-Ebenen.
Es geht vor allem um das Verhalten bei zwei komplett getrennten Requests - darf ich da immer dieselbe boundary benutzen?
»» Wie sieht es aber bei der Content-Id aus? Klar, innerhalb eines Requests müssen die Werte sich unterscheiden.
»» Aber darf ich bei einem weiteren Request die Content-Id-Werte wiederverwenden?
»» [...]
»» Aus der RFC zu multipart/relative (2387) konnte ich das nicht rauslesen.
In den thematisch verwandten RFCs 2045 und 2046 kann ich auch keinen entsprechenden Hinweis finden. Ich bin daher auch völlig deiner Meinung, dass die CIDs innerhalb *einer* Message eindeutig sein müssen, damit aber ihre Schuldigkeit getan haben und in weiteren Messages/Requests beliebig wiederverwendet werden können.
Danke. Bekräftigt meine Vermutung. Aber leider auch noch nichts eindeutiges, nur "es gibt keine eindeutige Aussage, die dagegen spricht".
cu,
Andreas
Warum nennt sich Andreas hier MudGuard?
O o ostern ...
Fachfragen unaufgefordert per E-Mail halte ich für unverschämt und werde entsprechende E-Mails nicht beantworten. Für Fachfragen ist das Forum da.