OK now I do have the timestamp from a TS provider.
How am I supposed to put it in a mime message so to comply with the standards?
As far as I know, no mailer supports timestamping, and this will not be a problem because I will be handling the mime message myself.
However I want to make it the standard way... any examples?
Thanks.
I think #Michael's own answer is just quite there with the following caveats:
An application/timestamp-replyis intended to transport a TimeStampResp which may or may not contain a TimeStampToken, and for the current purpose a TimeStampToken is always required to exist. See RFC 3161, "2.4.2. Response Format".
application/timestamp-reply content type is not currently defined as a security multipart protocol. See RFC 1847, "1. Introduction" and RFC 3161, "3.1. Time-Stamp Protocol Using E-mail".
Because of the previous I suggest the following sample structure:
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/timestamp-signature"; micalg="sha256"; boundary="{79EAC9E2-BAF9-11CE-8C82-00AA004BA90B}"
--{79EAC9E2-BAF9-11CE-8C82-00AA004BA90B}
MIME-Version: 1.0
Content-Type: text/plain
Hello
--{79EAC9E2-BAF9-11CE-8C82-00AA004BA90B}
Content-Type: application/timestamp-signature; name="tst.bin"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="tst.bin"
MIINygYJKoZIhvcNAQcCoIINuzCCDbcCAQMxDzANBglghkgBZQMEAgEFADB5BgsqhkiG9w0BCRAB
BKBqBGgwZgIBAQYLYIZIAYb9bgEHFwQwMTANBglghkgBZQMEAgEFAAQg7fR3pD+6Lw0dlYtTjYke
...
vlwFfWaVsUq6VyE0Sw3mVxQGooR7/GH10QSP7bNQqHNWyk1kX+9FlrRY3BPjsvJ046+ol74/3QkB
WA7ZrAGzhwRBPQKfkCXysHwtDIj7iF1YXcXoeKQ1SWiGjhIHCpCXMJwNiapZQfYsnZQbI6L/xXMA
--{79EAC9E2-BAF9-11CE-8C82-00AA004BA90B}--
Where
tst.bin is a TimeStampToken.
application/timestamp-signature is an non-standard security multipart protocol.
Edit:
There seems to be a couple of standards that could fit here:
RFC 5544 - "Syntax for Binding Documents with Time-Stamps"
RFC 5955 - "The application/timestamped-data Media Type"
But I did not have the time to check them in detail.
I believe this is the appropriate format:
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/timestamp-reply"; micalg="sha256"; boundary="{79EAC9E2-BAF9-11CE-8C82-00AA004BA90B}"
--{79EAC9E2-BAF9-11CE-8C82-00AA004BA90B}
MIME-Version: 1.0
Content-Type: text/plain
Hello
--{79EAC9E2-BAF9-11CE-8C82-00AA004BA90B}
Content-Type: application/timestamp-reply; name="smime.tsr"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.tsr"
MIIIUgYJKoZIhvcNAQcCoIIIQzCCCD8CAQMxDzANBglghkgBZQMEAgEFADCCAQ4G
CyqGSIb3DQEJEAEEoIH+BIH7MIH4AgEBBgorBgEEAbIxAgEBMDEwDQYJYIZIAWUD
BAIBBQAEIO30d6Q/ui8NHZWLU42JHpvHqwcukBtDCZiWtieBErjfAhQJsQprheA+
j/8hfRdCJYqNwURr+BgPMjAxNjA3MjgxMTM4NDdaoIGMpIGJMIGGMQswCQYDVQQG
EwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm
b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDEsMCoGA1UEAxMjQ09NT0RP
IFNIQS0yNTYgVGltZSBTdGFtcGluZyBTaWduZXKgggSgMIIEnDCCA4SgAwIBAgIQ
TrCHj8wkNTay2Mn3vzlVdzANBgkqhkiG9w0BAQsFADCBlTELMAkGA1UEBhMCVVMx
CzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMV
VGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0
cnVzdC5jb20xHTAbBgNVBAMTFFVUTi1VU0VSRmlyc3QtT2JqZWN0MB4XDTE1MTIz
MTAwMDAwMFoXDTE5MDcwOTE4NDAzNlowgYYxCzAJBgNVBAYTAkdCMRswGQYDVQQI
ExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoT
EUNPTU9ETyBDQSBMaW1pdGVkMSwwKgYDVQQDEyNDT01PRE8gU0hBLTI1NiBUaW1l
IFN0YW1waW5nIFNpZ25lcjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB
AM68dLdwgE9e8z+Yqi7L1BIBIzVpCyK85v0JbCjkExKsu7ot5dXdIu5ztiz40qRx
50kleKslt5AQoJuLdybdQOpBo/2IzXKmiTtQVxx6JSQiAlFANWeKMWkN5TlzSTmb
lQGFUvIrFImaTgSkvECuOabdQALgOnX+PX1VlFvxTiR8yLhYGcrA2r5YE5rmHOfR
wTvwXY9JCCGe0PO+1tRmT1xyNnvDgtOYCJSvq0RPGMcU2haxHjIOEjjAtTx27HVQ
ACAEERntxv/fTv4IgScxT3F0bgMMcCeBVWqaQ5Kkf9v9P8UXHkG7zuinf4yV+f1/
+GGIiQA+/wsB2/3VtaTkkRECAwEAAaOB9DCB8TAfBgNVHSMEGDAWgBTa7WR0FJwU
PKvdmam9WyhNizzJ2DAdBgNVHQ4EFgQUfb+R16dsWkdmRHuQ1I6QckGPF8IwDgYD
VR0PAQH/BAQDAgbAMAwGA1UdEwEB/wQCMAAwFgYDVR0lAQH/BAwwCgYIKwYBBQUH
AwgwQgYDVR0fBDswOTA3oDWgM4YxaHR0cDovL2NybC51c2VydHJ1c3QuY29tL1VU
Ti1VU0VSRmlyc3QtT2JqZWN0LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUH
MAGGGWh0dHA6Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEB
AFCw9d9frTPcw1NYWLzCE3V7IB1Uyro/UD+6ivRrCWPAW12L1nUac72L/0fxFdxR
FiMZMuZukk3Rxi5aHohCFMly5dcIUIpq9WRAVq4k42GXFULwLEiug+Y1PItbwo+u
jsw0UjTg+/7K/bEkaNGkESMQBv2ywiQnx9fpShyPPz7P7et1eWyOX/chtlDmJaHN
ZpQSbL/bs66H2GgDciACwn7alPNyBzxX6FUk5wWgHcSBAYJLHz8PnTOb8E/MndaF
gc/L5/1K6ZK49w1ycy3pd/lvjyh6Ph69CIbcjR4RX/dbu4d2xp5MVGHQZ9uThNox
hwOS55/j6c9aVsho4FJJlFwxggJxMIICbQIBATCBqjCBlTELMAkGA1UEBhMCVVMx
CzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMV
VGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0
cnVzdC5jb20xHTAbBgNVBAMTFFVUTi1VU0VSRmlyc3QtT2JqZWN0AhBOsIePzCQ1
NrLYyfe/OVV3MA0GCWCGSAFlAwQCAQUAoIGYMBoGCSqGSIb3DQEJAzENBgsqhkiG
9w0BCRABBDAcBgkqhkiG9w0BCQUxDxcNMTYwNzI4MTEzODQ3WjArBgsqhkiG9w0B
CRACDDEcMBowGDAWBBQ2Un1Pompo+etFlvHZmrssDqdt+jAvBgkqhkiG9w0BCQQx
IgQgXBnEfFijVzb4h7n7wGBdvQhBEzRn87M67RIUdRNe6dwwDQYJKoZIhvcNAQEB
BQAEggEACcjtqph0BQ20lchE0HZYg/4oL8KuPh1Vx5LL2cVaPcj2fruoXH58577E
XFQxhZ08HsjZtYdhVokRs2vbjM/i23HVDX+IkwGuESloFXhtoAt9hKNkyhXTtWx5
tt7TEJwi+o8/SU9bFnDqPMVn5Bg+QNnnegiCJzQ4lZnmTW2JiEmL3u7XzZ21FLZ7
KT/JqgOvBY3yvWySODN1yKVdhk5FkVKxBAxBgccPQ6nwmdm0RxqbsLdoSXFuRMi5
7sUgo113xR2VuvdJzl6d4iAYdUvuSRz94xXIQMQ9L307dKZ2yTYUQTy1YcSRxsZb
kTmkisjtzbXCyfC+AYB6dnoeBp3euQ==
--{79EAC9E2-BAF9-11CE-8C82-00AA004BA90B}--
Please edit me if I am wrong.
Any e-mail client that supports it so to verify?
Related
I'm trying to figure out SoapUI, and so far it's been a great tool. However, I cannot figure out this transferring of property stuff. I've read so much and just can't seem to find the answer I'm looking for.
I have one request: TC01_vorbereitenKunde
I receive the following Response Payload back:
HTTP/1.1 200 OK
X-Powered-By: Servlet/3.0
SOAPAction: "http://..."
Accept: text/xml
Content-Type: text/xml; charset=UTF-8
Content-Language: en-US
Date: Tue, 22 Sep 2015 15:58:01 GMT
Content-Length: 414
Content-Encoding: gzip
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Body>
<nova-kunden:vorbereitenKundeResponse xmlns:nova-kunden="http://...>
<nova-kunden:vorbereitungKundeAntwort>
<status>true</status>
<tkid>31f64d0f-b076-4304-95ab-15cb0de38adb</tkid>
<meldungen/>
</nova-kunden:vorbereitungKundeAntwort>
</nova-kunden:vorbereitenKundeResponse>
</soapenv:Body>
I then want to take the "tkid" value and place it in the following request: TC02_offeriereLeistungen
I've tried: ${TC01_vorbereitenKunde#Response#//tkid}
"TC01_vorbereitenKunde" is the name of the Test Step where the response payload is from to no avail.
What am I missing? Thank you so much in advance for your help!
Have script assertion for the first step as given below:
import com.eviware.soapui.support.XmlHolder
def xml = new XmlHolder(context.response)
def responseValue = xml.getNodeValue("//*:tkid")
assert null != responseValue, "Response does not have value"
context.testCase.setPropertyValue('TK_ID', responseValue)
In the second step, use ${#TestCase#TK_ID} where value is needed.
This is my first quesiton, but what I'm trying to do is send mail with an attachment in rails console, using one or two lines. I dont want to instantiate a class like ..
class Mailer < ActionMailer::Base
...
end
I want to try it this way:
m=ActionMailer::Base.mail(:to => "harry#example.com", :from => "test#example.com", :subject=>"test from zip", :content_type=>"multipart/mixed")
m.attachments['file.zip']={:mime_type => "application/zip", :data=>File.read("#{Rails.root}/tmp/test.zip")}
m.deliver
This will send an email, but the attachment called noname, which can't be unzipped. It seems that its not parsing the data correctly for the attachment. If I look at the raw email the attachment contents looks something like this:
--
Date: Tue, 06 Mar 2012 06:59:42 -0800
Mime-Version: 1.0
Content-Type: application/zip;
charset=UTF-8
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename=file.zip
Content-ID: <4f56264f16e82_498a46e93467093#ip-10-125-15-127.mail>
UEsDBBQAAAAIAE9iZUBSMYOwkKgZANRakgAQABUAbG9hbl9kZXRhaWxzLmNz
dlVUCQADlh9VT0QfVU9VeAQA6APoA8xdW3PiuLZ+37+Ch6ldZ1dZGUvyNW/c
EwKBQLiENze4gytgZ9tmMplff5YMlgQWmV1tk5qufiAkwV8trcu3bko/8sLa
m/+p9dmLJPXSfaI1oyR4Df21Non28crPvt+MfS/117Uo5C+9VKu/v8fRH4e3
O0HobWte9g68gHdaQfJjHyeHb4/9/+79JPu9XbQPU22y2kTRVuv74dqPa7G/
...
1) is it even possible to send an email with an attachment like this, with out using something like the pony gem
An estimation to why it isn't working
According to SO post Invalid filename in email (ActionMailer) it seems to be ActionMailer wanting to automagically glean information from files, something which is unavailable from the console.
I noted that the following, albeit messy, works (sufficiently for my purposes) from the console:
File.open("magical_elephant_potato.txt", 'w') {|f| f.write("Heyyyy youuu!") }
m=ActionMailer::Base.mail(:to => "rainbowpony#company.com", :from => "noreply#railsapp.com", :subject=>"Behold my MEP attache", :content_type=>"multipart/mixed")
m.attachments['magical_elephant_potato.txt']=File.read("magical_elephant_potato.txt")
m.deliver
FileUtils.rm('magical_elephant_potato.txt')
Given that writing and removing files via console works, perhaps the files required by ActionMailer can be written, utilised then deleted? We're heading into sticky work-around territory here though. A problem is that ActionMailer will look for the appropriate mailer view, but how and can we tell ActionMailer where to look for the mailer files? (As in, the filename)
As for the information not being encoded correctly, I think the problem is that its being wrapped in the 'noname' file with some header info. The data is likely intact, as with my example I get:
--
Date: Tue, 08 Jan 2013 11:08:57 +0000
Mime-Version: 1.0
Content-Type: text/plain;
charset=UTF-8;
filename=magical_elephant_potato.txt
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=magical_elephant_potato.txt
Content-ID: <50bbfe4898ac_6d7febf6a312062#ws9.companydev.com.mail>
Heyyyy youuu!
----
:when I open 'noname' with a text editor.
I'm try to add binary file data directly to the request body of a POST call so I can simulate a file upload. However, I tried setting a 'before request' breakpoint and using 'insert file' but I couldn't seem to get that to work. I also tried to modify CustomRules.js to inject the file but couldn't figure out how to load binary data via JScript. Is there an easy solution here?
I'm sure this is a new feature in the year since this question was answered, but thought I'd add it anyhow:
There's a blue "[Upload file]" link in Composer now on the right side under the URL textbox. This will create a full multipart/form-data request. If you use this, you'll notice in the body you now have something that looks like this:
<#INCLUDE C:\Some\Path\my-image.jpg#>
In my case, I just wanted to POST the binary file directly with no multipart junk, so I just put the <#INCLUDE ... #> magic in the request body, and that sends the binary file as the body.
In order to send multipart/form-data, this receipe will be helped.
In upper panel (Http header), set Content-Type as below. Other values are automatically resolved.
Content-Type: multipart/form-data; boundary=-------------------------acebdf13572468
And, input Response Body at the below panel as follows.
---------------------------acebdf13572468
Content-Disposition: form-data; name="description"
the_text_is_here
---------------------------acebdf13572468
Content-Disposition: form-data; name="file"; filename="123.jpg"
Content-Type: image/jpg
<#INCLUDE *C:\Users\Me\Pictures\95111c18-e969-440c-81bf-2579f29b3564.jpg*#>
---------------------------acebdf13572468--
The import rules are,
Content-Type should have two more - signs than boundary words in body.
The last of the body should be ended with two - signs.
In Fiddler script: (in Fiddler: Rules... Customize Rules), find the OnBeforeRequest function, and add a line similar to:
if (oSession.uriContains("yourdomain"))
{
oSession.LoadRequestBodyFromFile("c:\\temp\\binarycontent.dat");
}
since version 2.0, the Request Body has an "Upload File..." link that allows you to post/upload binary data.
Is there any way we could get directly say the 1000 characters after the first 5000 characters, skipping everything before that after sending in an HTTP request to an HTTPS page using either GET or POST in VB.NET?
The reason why I ask this question is because in one of the webpage I am trying the get through my program, the website is sending response data in chunks with the first chunk containing some javascript garbage that I have no interest in, the only data I care is in the second chunk and
I have no idea how to get the second chunk after receiving the first one since it is within the same HTTP request
It would save some time and Internet traffic if I can skip the first chunk that I do not need.
Is that possible or I am just day dreaming?
Many thanks!
ADDED:
Here is how a typical header of the response I am getting from the webpage I am trying to get:
Date: Mon, 20 Jun 2011 13:21:56 GMT
Set-Cookie: JSESSIONID=1AF1AF9EF936E1CB2FA85B750EDC67C4; Path=****some path******; Secure
Content-Type: text/html; charset=ISO-8859-1
Transfer-Encoding: chunked
Set-Cookie: **********some cookie***************
path=/
Vary: Accept-Encoding, User-Agent
Not sure if that helps, but as you can see, the chunk size is not visible to me, there is no "Trailer" in the header as well.
Fun little problem. Look at RANGE in the following GET request.
GET /file.txt HTTP/1.1
Host: localhost
Range: bytes=5000-6000
Connection: Close
Edit: Found a HTTP example.
Here is an example in PHP. (Sorry I couldn't find any VB.NET examples).
I have not found any specification about whether duplicate HTTP response headers are allowed by the standard, but I need to know if this will cause compatibility issues.
Say I have a response header like this:
HTTP/1.1 302 Moved Temporarily
Server: Apache-Coyote/1.1
X-Powered-By: Servlet 2.4; JBoss-4.0.3SP1 (build: CVSTag=JBoss_4_0_3_SP1 date=200510231054)/Tomcat-5.5
Cache-Control: no-cache
Cache-Control: no-store
Location: http://localhost:9876/foo.bar
Content-Language: en-US
Content-Length: 0
Date: Mon, 06 Dec 2010 21:18:26 GMT
Notice that there are two Cache-Control headers with different values. Do browsers always treat them as if they are written like "Cache-Control: no-cache, no-store"?
Yes
HTTP RFC2616 available here says:
Multiple message-header fields with the same field-name MAY be present
in a message if and only if the entire field-value for that header
field is defined as a comma-separated list [i.e., #(values)]. It MUST
be possible to combine the multiple header fields into one
"field-name: field-value" pair, without changing the semantics of the
message, by appending each subsequent field-value to the first, each
separated by a comma. The order in which header fields with the same
field-name are received is therefore significant to the interpretation
of the combined field value, and thus a proxy MUST NOT change the
order of these field values when a message is forwarded
So, multiple headers with the same name is ok (www-authenticate is such a case) if the entire field-value is defined as a comma-separated list of values.
Cache-control is documented here: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9 like this:
Cache-Control = "Cache-Control" ":" 1#cache-directive
The #1cache-directive syntax defines a list of at least one cache-directive elements (see here for the formal definition of #values: Notational Conventions and Generic Grammar)
So, yes,
Cache-Control: no-cache, no-store
is equivalent to (order is important)
Cache-Control: no-cache
Cache-Control: no-store
Note that the HSTS RFC6797 contradicts the RFC2616 (violating the "if and only if" language) by defining the behavior for multiple instances of the STS header, though it is not populated with comma-separated values:
"If a UA receives more than one STS header field in an HTTP
response message over secure transport, then the UA MUST process
only the first such header field."