multipart/related, Content-Id-Fragen

[MudGuard]

Hi,

wenn ich einen Request mit multipart/related content-type schicke, sieht der body ja z.B. so aus:

------=_Part_9_8514003.1239263309918
Content-Type: text/xml; charset=UTF-8
Content-Transfer-Encoding: binary
Content-Id: <9621AD2DA9D1FAAD65BF4269A5A438C2>

<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
 soapenv:Body/
</soapenv:Envelope>
------=_Part_9_8514003.1239263309918
Content-Type: text/plain
Content-Transfer-Encoding: binary
Content-Id: <96D58B1711F52FB97CD55A296E0D82AC>

<?xml version="1.0" encoding="iso-8859-1"?>
<bla/>
------=_Part_9_8514003.1239263309918--

Dazu dann noch der header (die für die Frage nicht relevanten Header lasse ich weg):
Content-Type: multipart/related; type="text/xml"; start="<9621AD2DA9D1FAAD65BF4269A5A438C2>"; boundary="----=_Part_9_8514003.1239263309918"

Hier tauchen ja mehrere Ids auf - zum einen zweimal die Content-Id und zum anderen die boundary.

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).

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?
Das würde mir die Sache wesentlich vereinfachen.

Aus der RFC zu multipart/relative (2387) konnte ich das nicht rauslesen.

Danke im Voraus,
cu,
Andreas

[Tom]

Hello,

Aber darf ich bei einem weiteren Request die Content-Id-Werte wiederverwenden?
Das würde mir die Sache wesentlich vereinfachen.

Aus der RFC zu multipart/relative (2387) konnte ich das nicht rauslesen.

also nur als Erfahrungswert:
Die Content-ID kann auch inline wieder auftauchen, wenn Du z.B. eine HTML-Mail mit Bildern verschickst und nun sillst, dass der Client, die Bilder aus dem mitglieferten Content an der passenden Stelle einstanzt.

<img style="width: 112px; height: 19px;" alt="" src="cid:logobild">

In soweit muss sie dann eindeutig sein.

Für andere Zwecke müssen die CIDs mMn gar nicht vorhanden sein, können es aber.
Wenn Du sie eindeutig vergibst, z.B. über eine Datenbank verwaltest, könntest Du aber später bei einem automatischen Verwaltungssysem die Zuordnung der Antworten leichter vornehmen.

Liebe Grüße aus dem Cyberspace

Tom vom Berg

[MudGuard]

Hi,

»» Aber darf ich bei einem weiteren Request die Content-Id-Werte wiederverwenden?
»» Das würde mir die Sache wesentlich vereinfachen.
»»
»» Aus der RFC zu multipart/relative (2387) konnte ich das nicht rauslesen.

also nur als Erfahrungswert:
Die Content-ID kann auch inline wieder auftauchen, wenn Du z.B. eine HTML-Mail mit Bildern verschickst und nun sillst, dass der Client, die Bilder aus dem mitglieferten Content an der passenden Stelle einstanzt.

Ok.

In soweit muss sie dann eindeutig sein.

Das ist schon klar, daß die Verwendung per cid: mehrfach vorkommen darf, aber für die einzelnen Content-Id: Angaben verschiedene Werte.

Wenn Du sie eindeutig vergibst, z.B. über eine Datenbank verwaltest,

Nein. Genau diesen Aufwand will ich mir eigentlich sparen.
Da es um mehrere Tausend Requests pro Stunde geht, ist alles, was Laufzeit spart, relevant.

cu,
Andreas

[Tom]

Hello,

hier noch ein Link auf eine recht aussagefähige Zusammenstellung bezüglich MIME-Mail
http://www.tu-chemnitz.de/urz/mail/mime.html

Liebe Grüße aus dem Cyberspace

Tom vom Berg

[MudGuard]

Hi,

hier noch ein Link auf eine recht aussagefähige Zusammenstellung bezüglich MIME-Mail
http://www.tu-chemnitz.de/urz/mail/mime.html

Danke, aber in den RFCs hab ich nichts über Cross-Request-Eindeutigkeit der Content-Ids gefunden. Sonst hätte ich ja gar nicht erst hier gefragt.

cu,
Andreas

[Der Martin]

Hallo,

wenn ich einen Request mit multipart/related content-type schicke

du meintest sicher einen Response. ;-)

------=_Part_9_8514003.1239263309918
Content-Type: text/xml; charset=UTF-8
Content-Transfer-Encoding: binary
Content-Id: <9621AD2DA9D1FAAD65BF4269A5A438C2>

[...]
------=_Part_9_8514003.1239263309918
Content-Type: text/plain
Content-Transfer-Encoding: binary
Content-Id: <96D58B1711F52FB97CD55A296E0D82AC>

[...]
------=_Part_9_8514003.1239263309918--

So in etwa kann das aussehen, diese Struktur wird ja im Prinzip auch in HTML-Mails verwendet.

Content-Type: multipart/related; type="text/xml"; start="<9621AD2DA9D1FAAD65BF4269A5A438C2>"; boundary="----=_Part_9_8514003.1239263309918"

Der start-Parameter ist optional, wie ich eben gelesen habe; wird er weggelassen, gilt "the first part" als Start.

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. Die Frage ist nur bei mehrfach verschachtelten Nachrichten sinnvoll, etwa HTML-Mails: Hier habe ich zunächst multipart/alternative, normalerweise mit einem Teil in text/plain und einem in multipart/related, der wiederum das HTML-Dokument und die eingebundenen Ressourcen enthält.
Theoretisch kann man die Teile als in sich abgeschlossene Einheiten parsen, so dass man über alle Hierarchieebenen dieselbe Boundary verwenden könnte. Ich habe aber mal irgendwo gelesen, dass man das nicht tun sollte ("SHOULD NOT"), kann mich aber weder erinnern, wo das war, noch welchen Grund das haben sollte.

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.

So long,
 Martin

[MudGuard]

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

[Tom]

Hello,

»» wenn ich einen Request mit multipart/related content-type schicke

[...]

Da unterliegst Du also den Speilregeln für HTTP?
Dann solltest Du dort nochmal nachschauen:

"The MIME header fields within each body-part of a multipart message- body do not have any significance to HTTP beyond that defined by their MIME semantics."

http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.7.2

Es kommt also vermutlich nur auf Deine Ziel-Applkikation an, wie die das verwursten kann/muss.
Der Transfer-Strecke scheint es egal sein zu müssen :-)

Liebe Grüße aus dem Cyberspace

Tom vom Berg

[MudGuard]

Hi,

»» > »» wenn ich einen Request mit multipart/related content-type schicke
[...]
Da unterliegst Du also den Speilregeln für HTTP?

Ja.

Dann solltest Du dort nochmal nachschauen:
"The MIME header fields within each body-part of a multipart message- body do not have any significance to HTTP beyond that defined by their MIME semantics."
http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.7.2

Es kommt also vermutlich nur auf Deine Ziel-Applkikation an, wie die das verwursten kann/muss.

Ok. Die ist extern. Da hilft dann wohl nur try and (hopefully not) err ...

cu,
Andreas

[Tom]

Hello,

Ok. Die ist extern. Da hilft dann wohl nur try and (hopefully not) err ...

hier noch eine RFC
http://www.rfc-editor.org/pipermail/rfc-dist/2002-June/000026.html
ftp://ftp.rfc-editor.org/in-notes/rfc3288.txt

Vielelicht hilft Dir das weiter?

Liebe Grüße aus dem Cyberspace

Tom vom Berg

[Tom]

Hello,

ftp://ftp.rfc-editor.org/in-notes/rfc3288.txt

Vielelicht hilft Dir das weiter?

Das sieht nicht gut aus:

Further note that MIME[9]
   requires that the value of the "Content-ID" header be globally
   unique.

Liebe Grüße aus dem Cyberspace

Tom vom Berg