#55 Change Content Type for attachment
Hi chip,
first of all many thanks for the adjustments that you made for us in blat by now. This is all perfect.
We have used your adjustment to change the content-disposition now for a long time, but now we are forced for another application to change the content-type from application/xml to application/fhir+xml.
Is this allready possible with blat?
To change the content-disposition we use this notation:
-attach "c:\temp\test.xml<eab-xml>"</eab-xml>
But I have no idea how to change the content-type.
I use this command line to create the message without the changed content-type:
"C:\QMED\Programme\blat\blat.exe" -q -to "xxx@kv-safenet.de" -server localhost -port 25 -u xxx -pw xxxxx -f "qmed.praxis.test.Ref_eins@kv-safenet.de" -log C:\QMED\DATEN\1click\blat\ets_15072019_095342.log -s "eTS;Vermittlungscode-Anforderung-Muster06;V2.0" -attach "C:\QMED\Daten\Profiles\27\temp\Vermittlungscode-Anforderung-Muster06.xml" -x "X-KVC-Dienstkennung: eTS;Vermittlungscode-Anforderung-Muster06;V2.0" -x "X-KVC-Sendersystem: Q-MED;291.0" -superdebugT -body "Body"
The created message looks like this:
--=_BlatBoundary-uJ4XrZxT33JACL73nTMvU
Content-Type: application/xml;
name="Vermittlungscode-Anforderung-Muster06.xml"
Content-Transfer-Encoding: BASE64
Content-Disposition: ATTACHMENT;
filename="Vermittlungscode-Anforderung-Muster06.xml"
But the header has to be:
--=_BlatBoundary-uJ4XrZxT33JACL73nTMvU
Content-Type: application/fhir+xml;
name="Vermittlungscode-Anforderung-Muster06.xml"
Content-Transfer-Encoding: BASE64
Content-Disposition: ATTACHMENT;
filename="Vermittlungscode-Anforderung-Muster06.xml"
Thanks for your support.
Heiko Mück
Hi Chip,
I have to correct my last post. Last year we talked about this problem in another ticket. I forget it.
In this ticket you told me, that I could change in HKEY_CLASSES_ROOT the content-type.
If I delete this value, I can use the -content-type option for all attachments.
Would it be possible, to use -content-type also if a value is specified in HKEY_CLASSES_ROOT.
It would be very much work to change it in lot of systems.
Thanks
Heiko
Hi Chip,
I have talked in the meantime with the institution where we have to send the message to.
They say, that we had to change the Content-Type from
Content-Type: application/xml; name="Vermittlungscode-Anforderung-Muster6.xml"
to:
Content-Type: application/xml; charset="utf.8"; name="Vermittlungscode-Anforderung-Muster6.xml"
That means: we have to transfer a charset for the attachment. Is that allready possible with blat?
And another question:
I would like to send the message without a readable body. If I do not use the -body option, I can not send the message, because blat is waiting for an input.
Is it possible to send without standard body?
Greetings
Heiko Mück
Good day, Heiko.
Have you tried sending your message with the .xml file, and using -charset "utf-8" ? I am looking at the source where I am building the headers, and see that I add charset: to the Content-Type: header.
As for sending a message without a body, have you tried -body "", or using -bodyF <somefile> where the file is zero bytes length?</somefile>
I can check both of these issues tonight.
Chip
Hello Chip,
the last try was this:
"C:\QMED\Programme\blat\blat.exe" -q -to "xxx" -server localhost -port 25 -u qmed.praxis.test.Ref_eins -pw xxx -f "xxx" -log C:\QMED\DATEN\1click\blat\ets_15072019_172508.log -s "eTS;Vermittlungscode-Anforderung-Muster06;V2.0" -attach "C:\QMED\Daten\Profiles\27\temp\Vermittlungscode-Anforderung-Muster06.xml" -x "X-KVC-Dienstkennung: eTS;Vermittlungscode-Anforderung-Muster06;V2.0" -x "X-KVC-Sendersystem: Q-MED;291.0" -superdebugT -force8bit -charset "utf-8" -body "Body"
That was the interesting part of the log:
This is a multi-part message in MIME format.
--=_BlatBoundary-x5DBiNnl3cOQ3hMjWRZjh
Content-Transfer-Encoding: 8BIT
Content-Type: text/plain;
charset="UTF-8"
Body
--=_BlatBoundary-x5DBiNnl3cOQ3hMjWRZjh
Content-Type: application/fhir+xml;
name="Vermittlungscode-Anforderung-Muster06.xml"
Content-Transfer-Encoding: BASE64
Content-Disposition: ATTACHMENT;
filename="Vermittlungscode-Anforderung-Muster06.xml"
PEJ1bmRsZSB4bWxucz0iaHR0cDovL2hsNy5vcmcvZmhpciI+DQoJPGlkIHZhbHVlPSJkNzUzNDcz
Yy0zNGYyLTQ1NzYtYTRlOC1lNzRlNTU1ZWYxNGUiLz4NCgk8bWV0YT4NCgkJPHByb2ZpbGUgdmFs
The charset and the content-transfer-encoding of the body changed, but not the content-typ for the xml-document.
It has to look the following way:
Content-Type: application/fhir+xml; charset="utf-8";
name="Vermittlungscode-Anforderung-Muster06.xml"
If there is no other way, it would be nice to specify the charset for every single attachment.
You made a option for me, to specify the content-disposition for every single attachment, the expression is -attach "c:\temp\test.xml<content-disp>.". Maybe we could use something like "c:\temp\test.xml[charset]" or "c:\temp\test.xml[*Content-Type: application/fhir+xml; charset="utf-8";
name="Vermittlungscode-Anforderung-Muster06.xml] </content-disp>
Or do you have another idea?
The problem with the body seems not so important after my correspndence with the insitution, I can specify anything there without any problems. So you can forget that question.
Hava a nice day
Heiko
I am looking at the source, thinking I may need to make some changes. However, your above options tell Blat to send a binary attachment, which means that I cannot determine the character set, nor should I specify the character set for binary files. Text and inline attachments can have the character set noted. Embedded attachments treated almost the same as binary files.
Try your experiment again but use -attachT option. The letter T can be uppercase or lowercase, I made it big here only for reading.
Chip
Last edit: Chip 2019-07-16
Hi Chip,
that doesn't work for my use-case. By using -attacht nothing else fits except for the charset. You can see it in the example:
Content-Type: text/plain;
name="Vermittlungscode-Anforderung-Muster06.xml";
charset="UTF-8"
Content-Transfer-Encoding: 7BIT
Content-Disposition: ATTACHMENT;
filename="Vermittlungscode-Anforderung-Muster06.xml"
Content-Description: "Vermittlungscode-Anforderung-Muster06.xml"
I need:
Content-Type: application/fhir+xml; charset="utf-8"; charset="utf-8";
name="Vermittlungscode-Anforderung-Muster06.xml"
Content-Transfer-Encoding: BASE64
Content-Disposition: ATTACHMENT;
filename="Vermittlungscode-Anforderung-Muster06.xml"
PEJ1bmRsZSB4bWxucz0iaHR0cDovL2hsNy5vcmcvZmhpciI+DQoJPGlkIHZhbHVlPSJkNzUzNDcz
Yy0zNGYyLTQ1NzYtYTRlOC1lNzRlNTU1ZWYxNGUiLz4NCgk8bWV0YT4NCgkJPHByb2ZpbGUgdmFs
The problem is, that the parameters must exactly look the way I showed you in the example.
The only problem in the -attach version is, that
Content-Type: application/fhir+xml; charset="utf-8"; charset="utf-8";
name="Vermittlungscode-Anforderung-Muster06.xml" is missing. Everything else fits perfect.
Do you have any idea? Or would it be possible to make something like this?
"c:\temp\test.xml[charset]" or "c:\temp\test.xml[*Content-Type: application/fhir+xml; charset="utf-8";
name="Vermittlungscode-Anforderung-Muster06.xml]
Greetings Heiko
Thank you for that, Heiko.
I think I found an issue with text attachments when I tested yesterday morning, so I will be looking at attachment processing to improve it. I will also look at what I can do to support adding charset to the Content-Type for binary files.
I have a question for you regarding your files. Do your files include a UTF-8 or Unicode byte order marker (BOM) at the start of the files? This would most accurately tell the reader of your files that Unicode characters are encoded within.
If you were to get a hex dump of blat's log files, you should find a BOM in the first bytes of the log.
Chip
Hi Chip,
this is an example with superdebug:
2019.07.17 19:25:44 (Wed)------------Start of Session-----------------
Blat v3.2.20 (build : May 22 2018 10:01:17)
32-bit Windows, Full, Unicode
superDebug: init_winsock(), WSAStartup() returned 0 (NO_ERROR)
superDebug: Hostname <localhost> resolved to ip address 127.0.0.1
superDebug: Official hostname is HEIKO-WIN7
superDebug: Attempting to connect to ip address 127.0.0.1, on port 25
superDebug: Received 36 bytes:
superDebug: 00000 32 32 30 20 53 4D 54 50 20 73 65 72 76 65 72 20 220 SMTP server
superDebug: 00010 28 4B 56 2D 43 6F 6E 6E 65 63 74 29 20 72 65 61 (KV-Connect) rea
superDebug: 00020 64 79 0D 0A dy..
<<<getline<<< 220 SMTP server (KV-Connect) ready
superDebug: Attempting to send 17 bytes:
superDebug: 00000 45 48 4C 4F 20 68 65 69 6B 6F 2D 77 69 6E 37 0D EHLO heiko-win7.
superDebug: 00010 0A . </localhost>
Does it help you?
Greeting Heiko
Thank you for that log. Yes, it does help. For stuff like this in the future, it would be better to send it to me in a private email to chip.programmer@att.net.
As I suspected, your file is plain ASCII. Now for the sticky part. Adding charset to the Content-Type line tells the email reader how the BASE64 characters are encoded. BASE64 is defined as a 64 character subset of ASCII characters, therefore there will never be Unicode characters mixed into the BASE64 portion of the email message.
What is the purpose for adding charset to the Content-Type line? Is it that the recipient does not know that your .xml is plain ASCII, and wants to be told if the decoded data may contain Unicode characters? If that is what your recipient really wants, to be receiving Unicode / UTF-8 XML files, then your .xml files will need to have the Byte Order Marker (BOM) written before the first line of XML. In this case, there should be a three byte UTF-8 BOM represented by the hex bytes EF BB BF. When the recipient decodes the BASE64 portion, they will then know the xml is UTF-8 encoded because of the BOM in the first three bytes.
I welcome a discussion about what the purpose of adding charset to the Content-Type header line, when it actually make sense for it to be there. I found where to add the needed source changes, but I think there is some confusion about what the recipient really wants. Let us make sure of the true need for your recipient.
Last edit: Chip 2019-07-18
Hi Chip,
i don’t know the purpose. We use blat in this scenario to get a code from a server, that is hosted by a institution. The institution is the KBV. This institution is responsible for the health service in Germany and makes requirements for software and they are certifying the software. Only certified software is allowed to be used in the health care system. And at the moment we must become certified for the eTerminservice. And one of this requirements is, that this body must look the way it has to look. I think asking them why it has to be this way, will not be very succesful ;-)
It would be a great help for us, if you can implement this requirement. Everything else works perfect with blat (we really love blat, it helps us in many scenarios), only this little thing is missing.
Greetings Heiko
Last night, I added -addch2bin option for adding the charset= to Content-Type: headers. I have done only limited testing to ensure it works. I will run more tests later today with different attachment types, to see what the impact will be. I am not sure I have your email address still, please send me an email from an address, or with an address listed inside, where you can receive .zip files with executables inside. Also tell me whether you want 32-bit or 64-bit. I will guess that you want the "full" version that is normally downloadable from here at SourceForge.
Chip
Hi Chip,
thanks for your support. You can send it to h.mueck@q-med,de or to my private email adress heiki1975@gmx.de. It should work by both adresses with zip-archives with an exe inside. Please send me an additional email, that you send it, than I can check, if it works with this accounts.
At the moment the 32bit version is fine. I will test then immediately.
Heiko
Correct email is h.mueck@q-med.de
Hi Chip,
thank you for your support. It works for the problem, the content-type is not longer an error (they are using a automatic check for the messages we send), but now I get another error, that I does not understand:
<fehlermeldung> <messageid>%3C01d53dff%24Blat.v3.2.22%249552c4d0%2425a05a8254ff%40localhost%3E</messageid> <fehler>66</fehler> <fehlertext>Content-Transfer-Encoding für Fachlichen Inhalt nicht korrekt </fehlertext> </fehlermeldung>In my opinion, the content-transfer-encoding is correct (BASE64), but upper case.
In the specification it is lower case.
I will report you later.
Hi Chip,
I have a first feedback. The institution said, that BASE64 in upper-case is correct, but they must look, if they can change their test routines to accept it. I think, we should not do anything, they have to change it.
A big thank-you for your support so far.
Heiko
RFC 1341 describes the Content-Transfer-Encoding header at the bottom of page 10:
Content-Transfer-Encoding := "BASE64" / "QUOTED-PRINTABLE" / "8BIT" / "7BIT" / "BINARY" / x-token These values are not case sensitive. That is, Base64 and BASE64 and bAsE64 are all equivalent. An encoding type ofThe RFC goes on and uses both uppercase and lowercase values interchangeably. Follow-on RFCs also show the values in uppercase, primarily, but also in lowercase in their text. Some examples in the RFCs show uppercase values, some show lowercase values.
Before I upload the new files, I need to fix the ChangeLog.txt and run more tests. I hope there will not be more edits, then I should be able to upload the new files over the weekend.
Hi Chip,
thank you for the link. At the moment I am still waiting for an answer from the institution. We have talked in our company, and we do not want to change anything because of what RFC says. The insitutition had to change their test routines.
Greetings Heiko