Fehlende Umbrüche nach URLDecode

[Dominique M.]

Hallo,

schon wieder steh ich vor einem Rätsel...

Ein Agent soll mir eine Mailvorlage berechnen und das Ergebnis verschicken. Eine Mailvorlage hat bestimmte Textmarken die er erkennt und die festgelegte Formeln ersetzt und Evaluiert.
Nachdem die berechnung abgeschlossen ist zeigt er ein "Vorschau" Dokument mit dem Ergebnis an. Die Parameter für das neue Dokument hänge ich direkt an die URL dran (GET), so nun folgendes Problem, bevor die Parameter drangehängt werden, werden diese URLEncoded.

Bei dem neuen Dokument könnte ich per Query_String_Decoded den Original String wiederhaben und weiterverarbeiten. Doch egal wie ich die URL Dekodiere, er schmeiß mir jedesmal die Umbrüche raus und mein Ergebnis ist unvollständig!

Deswegen die Frage, wie ich das eleganter lösen kann!?!

Ich habe mir schon überlegt ein Document per Agent zu erstellen, füllen und abzuspeichern, doch soll diese Vorlage bzw. Vorschau nicht gespeichert werden, selbst Temporär speichern wäre zu "unsicher".

Ich hoffe Ihr könnt mir dabei helfen...

Vielen dank schonmal

Gruß

Dominique M.

[Dominique M.]

Ok Ergänzung: Es liegt wahrscheinlich sogar daran das die URL zulang wird bei den ganzen Parametern, ich wüsste spontan aber nicht wie ich die Parameter anders übergeben könnte...

[flaite]

Du kannst in URLs kein Whitespace packen (leerzeichen, carriage return, new line).
Du könntest vor dem URL-Encoding und vor oder nach dem Url-Decoding die entsprechenden chars durch Sonderzeichen maskieren, von denen du weisst, dass sie sonst nicht in der Mail vorkommen. Ist natürlich ein bischen problematisch.
Oder du erstellst das Dokument doch temporär und füllst dort Leserfelder (user und Server). Dann einen serverseitigen Agenten, der jede Stunde über 10 Minuten (oder so) alte Dokumente löscht.

[m3]

1) Die HTTP-Spezifikation definiert keine maximale Länge für URLs:

The HTTP protocol does not place any a priori limit on the length of a URI.

Die Browser-Hersteller allerdings schon.

2) Axel, man kann sehr wohl "Leerzeichen" in URLs packen. Ein Blank etwa als "%20" usw. (also "%" plus dem hexcodierten ASCII-Wert des Zeichens) in eine URL eingebunden werden. - Sollten nicht, aber es ist technisch möglich.

Dominique, wenn Du im Form enctype="multipart/form-data" angibst, werden die Parameter nicht in der URL übergeben, ev. hilft Dir das weiter.

[flaite]

Vielleicht gehts mit %0a für newline.

Parameter für das neue Dokument hänge ich direkt an die URL dran (GET), so nun folgendes Problem, bevor die Parameter drangehängt werden, werden diese URLEncoded.

Kannst du das nicht Urlencodes, nachdem die Parameter drangehängt worden sind 
Vielleicht wird dann automatisch das new line richtig maskiert. Wobei das wieder problematisch ist, da bekanntlich unterschiedliche Betriebssysteme verschiedene characters für new line benutzen (Windows: char13, char10, *Nix: char10 und Apple Macintosh wieder was anderes).

Architektonisch ist es ziemlich unsauber, für so etwas HTTP-GET zu nehmen.
Dein HTTP-GET-request erzeugt ja ein neues Dokument (auch wenns temporär ist).
Es ist aber eigentlich dafür gedacht, ein bestehendes Dokument vom Server zu holen.
Man muß das nicht ernst nehmen. Die REST-Webservices Leute tun aber genau das. Für die ist das eindeutig ein Fall für HTTP-PUT, was btw. auch von den meisten Java Web Frameworks nicht unterstützt wird (es gibt Ausnahmen). 

[Dominique M.]

Guten Morgen,

so wie es ausschaut liegt es wohl doch nicht an der Maximallänge der URL, dann muss der Fehler woanders liegen, vielen dank erstmal für diesen Tipp.

Die restlichen Tipps werd ich mal abarbeiten und rumprobieren evtl. hab ich irgendwo auch einfach nur ein Logikfehler drin...mal abwarten was sie neue Woche so bringt

Ansonsten vielen dank, schönen Wochenanfang euch noch!


// Dominique

[Dominique M.]

So, nochmal ich

Für alle eventuell interessierten:

Also das Problem lag am UrlEncode den ich auf den Kompletten Parameter String angewendet hatte. Wenn man das nur auf die Variablen anwendet dann geht das Super...zurückzuführen ist dieses Problem auf das Encodieren eines "=" sowie eines "&" Zeichens und weder JavaScript noch die Formelsprache hatten das richtig Interpretiert!

Klingt im nachhinein fast logisch

Also für den Moment scheint es zu klappen.


Nochmal schöne Grüße und danke für die Tipps...

// Dominique