EldoS | Feel safer!

Software components for data protection, secure storage and transfer

Getting 'text/html' is not a valid content type (error code is 10037)

Also by EldoS: RawDisk
Access locked and protected files in Windows, read and write disks and partitions and more.
#24953
Posted: 05/16/2013 09:31:34
by Roland Kossow (Standard support level)
Joined: 05/16/2013
Posts: 29

Hi,
I am evaluating Secure Blackbox EDI and get the error above, when trying to Load the receipt of the sample application.
Since I do not own the code of the components, I can just say the exception is thrown by the line Res := Receipt.Load(edtLoadReceiptFile.Text); in the send client.

Does anybody have an idea, what might cause this problem?

The original receipt received by the sender looks as follows ...
Connection: close
Content-Type: text/html; charset=ISO-8859-1
Content-Length: 682
AS2-From: as2
AS2-To: as1
AS2-Version: 1.0
Date: Thu, 16 May 2013 14:42:30 GMT
Message-ID: <201305161642300968@89425616>
Content-Type: multipart/report;
report-type="disposition-notification";
boundary="----=_NextPart_177_9541_4141006961917593"
Server: SecureBlackbox AS2 Receiver Demo


------=_NextPart_177_9541_4141006961917593
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 8bit

Your message has been received successfully. This does not guarantee that the message has been read or understood.
------=_NextPart_177_9541_4141006961917593
Content-Type: message/disposition-notification;
charset="us-ascii"
Content-Transfer-Encoding: 8bit

Original-Message-ID: <201305161642230185@43206725>
Received-Content-MIC: VwFB23KRjlInwm/DZVsoKE62fP0=, sha1
Final-Recipient: rfc822; as2
Original-Recipient: rfc822; as2
Disposition: automatic-action/mdn-sent-automatically;
processed

------=_NextPart_177_9541_4141006961917593--

====

If I delete the first Content-Type line ... the receipt load correct,
but why is the receipt send in a way, that is not loadable in the first place?
#24955
Posted: 05/16/2013 09:40:21
by Alexander Ionov (EldoS Corp.)

Thank you for contacting us.

It would be nice to take a look at the file content you attempt to load as a receipt.


--
Best regards,
Alexander Ionov
#24956
Posted: 05/16/2013 09:44:25
by Roland Kossow (Standard support level)
Joined: 05/16/2013
Posts: 29

Wow, whhat a fast response - I edited my initial post with the contents.

Best regards

Roland
#24957
Posted: 05/16/2013 10:10:19
by Alexander Ionov (EldoS Corp.)

As far as I understand, you use the VCL edition of SecureBlackbox. In this edition, the AS2 Receiver demo uses Indy HTTP Server component to accept incoming AS2 messages and send back AS2 receipts.
Our code did not add that first Content-Type line. We use a kind of trick to make Indy to mix AS2 receipt headers (produced by our classes) and HTTP headers (produced by Indy). But probably the trick got broken for your Indy edition.


--
Best regards,
Alexander Ionov
#24958
Posted: 05/16/2013 10:31:12
by Roland Kossow (Standard support level)
Joined: 05/16/2013
Posts: 29

So I would need to patch the Load function of the receiptclass by altering the inputfile in advance, once I obtained a license and go the source?

Can you give any information on when the new version of secureblackbox will be available and if it will support the Indy versions bundled with XE3 and XE4?

Best regards and thanks for your support.
#24959
Posted: 05/16/2013 11:07:38
by Alexander Ionov (EldoS Corp.)

Quote
Roland Kossow wrote:
So I would need to patch the Load function of the receiptclass by altering the inputfile in advance, once I obtained a license and go the source?

If you're going to develop a client side AS2 software, then you don't need to patch anything. Normal AS2 servers do not add that additional Content-Type header field, so the receipts are parsed successfully.
If you're going to develop a server side AS2 software, then I don't think that using Indy as a server core is a good idea.

Quote
Roland Kossow wrote:
Can you give any information on when the new version of secureblackbox will be available and if it will support the Indy versions bundled with XE3 and XE4?

I'll try to find why the Receiver sample is broken for new editions of Indy. If it's possible at all, the sample will be fixed.


--
Best regards,
Alexander Ionov
#24960
Posted: 05/16/2013 11:45:15
by Alexander Ionov (EldoS Corp.)

Ok, I've found a workaround for Indy coming with XE3. If you need it before next build of SecureBlackbox, just open the fMain.pas file of the Receiver demo, find the TfrmMain.ServerCommandGet method and modify the following piece of code (added lines are showed with bold font):
Code
// 4. After step 1 the RStream is positioned on the beginning of the message body.
//    Thus Indy rewinds the stream to its start, we need to copy the message body
//    to a temporary stream.
Temp := TMemoryStream.Create;
try
  Temp.CopyFrom(RStream, RStream.Size - RStream.Position);
  AResponseInfo.ContentStream := Temp;
  AResponseInfo.FreeContentStream := False;
  AResponseInfo.WriteContent;
finally
  FreeAndNil(Temp);
end;

Change the fragment to be as shown below:
Code
// 4. After step 1 the RStream is positioned on the beginning of the message body.
//    Thus Indy rewinds the stream to its start, we need to copy the message body
//    to a temporary stream.
Temp := TMemoryStream.Create;
try
  Temp.CopyFrom(RStream, RStream.Size - RStream.Position);
  // workaround for changes by RLebeau 5/15/2012 in Indy HTTP server;
  // now the component forcibly adds a Content-Type header field if a content
  // stream is assigned; so the response header must be sent before assigning
  // content data.
  AResponseInfo.ContentLength := Temp.Size;
  AResponseInfo.WriteHeader;
  AResponseInfo.ContentStream := Temp;
  AResponseInfo.FreeContentStream := False;
  AResponseInfo.WriteContent;
finally
  FreeAndNil(Temp);
end;

Now receipts seem to be loaded successfully.


--
Best regards,
Alexander Ionov
#24976
Posted: 05/18/2013 12:47:48
by Roland Kossow (Standard support level)
Joined: 05/16/2013
Posts: 29

Thanks a lot.
What would you suggest as the server core instead of Indy?
#24977
Posted: 05/18/2013 12:49:59
by Roland Kossow (Standard support level)
Joined: 05/16/2013
Posts: 29

Probably ...

https://www.eldos.com/sbb/desc-http.php

?
#24978
Posted: 05/18/2013 15:19:09
by Alexander Ionov (EldoS Corp.)

Quote
Roland Kossow wrote:
What would you suggest as the server core instead of Indy?

Sorry, I don't have anything to suggest. HTTP/AS2 server consists of at least two layers: HTTP request processing (receiving AS2 message) and transport layers.
For HTTP request processing you can use our HTTP Server component. Also you can use our SSL Server component for securing incoming HTTPS sessions.
But it's for you to decide which library to use as a transport layer. This layer is responsible for accepting incoming connections, receiving requests, and sending back responses produced by higher levels of protocol stack.
Sure, we have ability to accept incoming connections in our TElSocket class, but transport layer (espesially in hight performance servers) is not our specialization.


--
Best regards,
Alexander Ionov
Also by EldoS: Rethync
The cross-platform framework that simplifies synchronizing data between mobile and desktop applications and servers and cloud storages

Reply

Statistics

Topic viewed 3408 times

Number of guests: 1, registered members: 0, in total hidden: 0




|

Back to top

As of July 15, 2016 EldoS Corporation will operate as a division of /n software inc. For more information, please read the announcement.

Got it!