SIPP Scenario (version 1.0 don't send digits) - sipp

Folks,
I am trying to make calls to test a IVR Machine with SIPP.
First, I am using the Sipp v1.0 final version. But this version does not have support to send digits to IVR Machine. So system is unable to answer calls.
I tested using other versions too.
Here is my scenario:
<!DOCTYPE scenario SYSTEM "sipp.dtd">
<scenario name="Basic Sipstone UAC">
<send>
<![CDATA[
INVITE sip:12053#10.0.8.67 SIP/2.0
Via: SIP/2.0/UDP 10.0.4.147:5060;rport;branch=z9hG4bK386088
From: "sipp" <sip:11958251026#10.0.4.147:5070>;tag=8808
To: <sip:12053#10.0.8.67>
Call-ID: 1510678743-6088-NVT4147#10.0.4.147
CSeq: 45 INVITE
Max-Forwards: 70
User-Agent: NCH Software Express Talk 4.28
Contact: <sip:11958251026#10.0.4.147:5060>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, INFO, REFER, NOTIFY
Supported: replaces
Content-Type: application/sdp
Content-Length: 328
v=0
o=NCHSoftware-Talk 1510678729 1510678743 IN IP4 10.0.4.147
s=Express Talk Call
c=IN IP4 10.0.4.147
t=0 0
m=audio 8000 RTP/AVP 0 8 96 3 13 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:96 G726-32/8000
a=rtpmap:3 GSM/8000
a=rtpmap:13 CN/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=sendrecv
]]>
</send>
<recv response="100" optional="true">
</recv>
<recv response="180" optional="true">
</recv>
<recv response="183" optional="true">
</recv>
<recv response="200">
</recv>
<send>
<![CDATA[
ACK sip:12053#10.0.8.67:5060;user=phone SIP/2.0
Via: SIP/2.0/UDP 10.0.4.147:5060;rport;branch=z9hG4bK396088
To: <sip:12053#10.0.8.67>;tag=7831-08A1
From: "sipp" <sip:11958251026#10.0.4.147:5070>;tag=8808
Call-ID: 1510678743-6088-NVT4147#10.0.4.147
CSeq: 45 ACK
Max-Forwards: 20
User-Agent: NCH Software Express Talk 4.28
Content-Length: 0
]]>
</send>
<nop>
<action>
<exec play_pcap_audio="pcap/g711a.pcap"/>
</action>
</nop>
<pause milliseconds="8000"/>
<nop>
<action>
<exec play_pcap_audio="pcap/dtmf_2833_1.pcap"/>
</action>
</nop>
<pause milliseconds="3000"/>
<send>
<![CDATA[
BYE sip:12053#10.0.8.67:5060;user=phone SIP/2.0
Via: SIP/2.0/UDP 10.0.4.147:5060;rport;branch=z9hG4bK26088
From: "sipp" <sip:11958251026#10.0.4.147:5070>;tag=8795
To: <sip:12053#10.0.8.67>;tag=7831-2E51
Call-ID: 1510678730-6088-NVT4147#10.0.4.147
CSeq: 107 BYE
Max-Forwards: 20
Subject: Performance Test
Content-Length: 0
]]>
</send>
<recv response="200" crlf="true">
</recv>
<ResponseTimeRepartition value="10, 20, 30, 40, 50, 100, 150, 200"/>
<CallLengthRepartition value="10, 50, 100, 500, 1000, 5000, 10000"/>
</scenario>
But, the answer is that (when I am using de version 1.0):
2017-11-16 19:31:46: Unknown element 'nop' in xml scenario file.
Please, help me.

SIPP can do complex SIP scripts but it is very limited for Voice interactions...
If you plan to test the IVR with Voice/DTMF interactions, try with Asterisk.
You can use a Dialer Script (We can provide one) to apply to your IVR a charge, with a Dialpan you can create complex scripting (with random).

Related

Need a Extract XPath help on an Email using webhook.site

I am needing to extract specific lines from a raw email that i have coming into my webhook.site url. I figured it would be an xpath extract or some custom action but my knowledge only goes so far.
i need to extract: Subject: which is the header about the content-type: text/plain.
Whats my path and layout to do so??
thanks
Return-Path: <leadnotification-noreply2#ylopo.com>
Received: from mail-lf1-f53.google.com (mail-lf1-f53.google.com [209.85.167.53])
by inbound-smtp.eu-west-1.amazonaws.com with SMTP id nqoso8q41s14sho14modqhpqbqvvvcqb0e3hea81
for OsirsYlopoPriorityEmail#email.webhook.site;
Wed, 27 Oct 2021 19:21:34 +0000 (UTC)
X-SES-Spam-Verdict: PASS
X-SES-Virus-Verdict: PASS
Received-SPF: pass (spfCheck: domain of ylopo.com designates 209.85.167.53 as permitted sender) client-ip=209.85.167.53; envelope-from=leadnotification-noreply2#ylopo.com; helo=mail-lf1-f53.google.com;
Authentication-Results: amazonses.com;
spf=pass (spfCheck: domain of ylopo.com designates 209.85.167.53 as permitted sender) client-ip=209.85.167.53; envelope-from=leadnotification-noreply2#ylopo.com; helo=mail-lf1-f53.google.com;
dkim=pass header.i=#ylopo.com;
dmarc=pass header.from=ylopo.com;
X-SES-RECEIPT: AEFBQUFBQUFBQUFHdlpaMkNVNS9wd25QYmtqSU9xbGJBVzZJa0tSV1dCNWcwWFFwZFNUS1lweHpxY1A1NlRoSlZyU1NEM0drMlp3Q0Jpd0d2ZG1RUC9VYVRCbWt6UUhMdkFwOUJLS1NGYnFCSzQyVGpQK1loZzU0SkpIcy9pNnQ4aHhScnV2dG9sV2M5b2VnSzY4MU0vMm9JaWx5VDJOcW5WWllPRzhvNkp6VHdJSWNmbmJBd1lvZlF1WHdEQUNFRzkyM0dQQVkxdGgwS0NwUHAzcVo5dit5clgvOXFzdG8xMFJaTVpuMVRLcXUwVDNNMVRod3lWSDB0NStRNjNUcEMrZ2RwZ0dSZFBQcEQ2OXZ2bUFOMkI3UUhJYUNZdG5iM2hqMUZhV1NST0FBbHdwSUM5TDIySk11dWh2alN3VE9BbVhGWjlKditMUzQ9
X-SES-DKIM-SIGNATURE: a=rsa-sha256; q=dns/txt; b=AXzUmXzoB1/c89r/6eJBBuEUriK6kdQMMJRXPnBwlUC5oCKD1Apk+Av3zpg5yxj+4djsbxeCsSPIwkcYX6xlXUfWUQ/mi7pgHViuVh+r/NrEKptMjb5efdeH7/mls8tRzyaQQF+12LbSb0wBo2bTkcQLXkP3WvKP5OSFde3B620=; c=relaxed/simple; s=uku4taia5b5tsbglxyj6zym32efj7xqv; d=amazonses.com; t=1635362495; v=1; bh=5WqfRbOb11+ge2mx0Egi4AqA6n1lyVIU1IpAVg4H0dA=; h=From:To:Cc:Bcc:Subject:Date:Message-ID:MIME-Version:Content-Type:X-SES-RECEIPT;
Received: by mail-lf1-f53.google.com with SMTP id y26so8295478lfa.11
for <OsirsYlopoPriorityEmail#email.webhook.site>; Wed, 27 Oct 2021 12:21:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=ylopo.com; s=google;
h=mime-version:from:date:message-id:subject:to;
bh=nrZwBjOzEgZN0tQ61MtDEDWEj3XJn2q+y4Qx1/acY5A=;
b=gtj7GzFH9q0O2S1ynt3Qvhp5zgomrYmufqbSQ0qIjEalwk9Dd0lSI7MeOMrgNtjDFL
sGwRBO9L4ZW3yE5ZKmP/wSYKmVlerL51ZlTQQhuTXsxioymJto3j0ERWirJQj+BapzGT
HBxScQEwYkpqZqWX6KkCTjCzCGZqW+fp9vitHmgfqt1/nLiyZp+7WEbluw+rPQO0G7dR
CGObjTeYa0Fd+Dc8h/k/a7suZ2umrqqnl/HYaoY7BeMxhAJDP5TuaoAsjQh1EU9zqHY8
TJxcJZoo83n+7f8qVMSNpAstVynlmsH6h7nzW1q27pfeWWY6LgMRUjkKqrYIc4F8lsqR
98SQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20210112;
h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
bh=nrZwBjOzEgZN0tQ61MtDEDWEj3XJn2q+y4Qx1/acY5A=;
b=D/VtUGyzcVfTxi2x63V/3OC7ckHj1uuLlILVUNmOkMrvW6GWUJq7mKI9/D4UYXWc5i
Ybds0/Dktx6cDJUZbAiAYWOiYd56XMMc2O+Yoe36u+eREry29IJQXOLTcRj2KFcLGSWa
Me5GjcFPVBTuhjtxlPb41wCKhGmDevYEHDkbGIcoNp5w3weGobSPg8bLQNsEO/Hspn6y
4Q18s7uNIJ8X2o5DEevA8DrZfibThQ3X5HUFmpuaRT3089Qm3H92wiHv3rkn3fQFDnVY
4p/PcWw9bxK6pU47bBtO/qtJ2ce/3Q7OQq/NCvJ5ZjD83lRai1mKIaCtiyt3gccQrd5S
hc5g==
X-Gm-Message-State: AOAM531woVO34G4bG9aVBLV9ae6QgX8pklYV4DDYs4VALPxuz7W9GStL
QM3YDolGrDOXbzaZghT/1+So8DR3WqejlOCELMsa+zO2Xxs=
X-Google-Smtp-Source: ABdhPJylxjs2zEdxsuBr2M1l9CnsOHrWvk+53vOLw2bs77bdl75s4022uZaKlqYx/GG+UyEsRrt8DT6mRRCAQZSebbE=
X-Received: by 2002:a05:6512:acf:: with SMTP id n15mr578213lfu.222.1635362493750;
Wed, 27 Oct 2021 12:21:33 -0700 (PDT)
Received: from 927538837578 named unknown by gmailapi.google.com with
HTTPREST; Wed, 27 Oct 2021 12:21:33 -0700
MIME-Version: 1.0
From: leadnotification-noreply2#ylopo.com
Date: Wed, 27 Oct 2021 12:21:33 -0700
Message-ID: <CAN2r-3o0aD_98y2GrdxdBW7W6UHi8RMS9-JmvsHrftheurwMeQ#mail.gmail.com>
Subject: Ylopo Priority Alert - Party: Daniel Askew 19293 -
PRIORITY_LEAD_EVENT - massaquoimartha#yahoo.com - 8562838525
To: OsirsYlopoPriorityEmail#email.webhook.site, qojfsghi#mailparser.io
Content-Type: multipart/alternative; boundary="00000000000084f8be05cf5a80dc"
--00000000000084f8be05cf5a80dc
Content-Type: text/plain; charset="UTF-8"
Lead Name: Martha Mansaray
Lead Email: massaquoimartha#yahoo.com
Lead Phone: 8562838525
Text:
Ylopo PRIORITY LEAD ALERT: Martha Mansaray (856) 283-8525
Martha Mansaray VIEWED 6185 Old Highway 31E, Bethpage, TN
<https://andrea.livetn.com/listing-detail/124037148> 29 TIMES.
Recommend actions:
I think you need regex because XPath is used to find a node from XML/HTML type text. But regex can be used on any text. To get the value of header name "Subject" you can use regex \nSubject: (.*).
Python example:
import re
sample = """
...
<text you want to parse>
...
Subject: Ylopo Priority Alert - Party: Daniel Askew 19293 -
"""
if match := re.search(r"\nSubject: (.*)", sample):
print(match.group(1)) # output: Ylopo Priority Alert - Party: Daniel Askew 19293 -

HTTP2 push and native ES modules: "entry" module push is ignored

I’ve been experimenting with approaches to serving native ES modules over HTTP2. Pretty much everything works great (where supported), but there’s a quirk that I can’t make much sense of.
Given a request for the / document, I push the resources which directly or indirectly are known to be dependencies of that document. In this case that ends up being three additional resources that piggyback via pushes:
/index.css (a dependency via <link href ...>)
/index.js (a dependency via <script type="module" src ...>
/routes.js (an indirect dependency, imported by index.js)
All three resources appear to push successfully from the server side. However, Chrome makes a second request for "/index.js" despite the push with the first request. Neither of the other two resources are requested; those pushed responses appear to be acknowledged correctly.
At first I thought this was a Chrome quirk, just a rough edge on a newly minted feature. But the same behavior is demonstrated in Firefox when the module support flag is enabled, which made me wonder if this is deliberate for some reason.
Logging from backend corresponding to above requests:
RECEIVED REQUEST: GET /
...PUSHING /index.css
...PUSHING /index.js
...PUSHING /routes.js
RECEIVED REQUEST: GET /index.js
...PUSHING /routes.js
Following up on the instructions from #sbordet: here are transcripts from both requests (great to know this stuff can be introspected in Chrome!):
First Req (/)
3067: HTTP2_SESSION
death.tips:443 (DIRECT)
Start Time: 2017-10-09 10:49:24.597
t=304289 [st= 0] +HTTP2_SESSION [dt=?]
--> host = "death.tips:443"
--> proxy = "DIRECT"
t=304289 [st= 0] HTTP2_SESSION_INITIALIZED
--> protocol = "h2"
--> source_dependency = 3064 (SOCKET)
t=304289 [st= 0] HTTP2_SESSION_SEND_SETTINGS
--> settings = ["[id:1 (SETTINGS_HEADER_TABLE_SIZE) value:65536]","[id:3 (SETTINGS_MAX_CONCURRENT_STREAMS) value:1000]","[id:4 (SETTINGS_INITIAL_WINDOW_SIZE) value:6291456]"]
t=304289 [st= 0] HTTP2_SESSION_UPDATE_RECV_WINDOW
--> delta = 15663105
--> window_size = 15728640
t=304289 [st= 0] HTTP2_SESSION_SEND_WINDOW_UPDATE
--> delta = 15663105
--> stream_id = 0
t=304289 [st= 0] HTTP2_SESSION_SEND_HEADERS
--> exclusive = true
--> fin = true
--> has_priority = true
--> :method: GET
:authority: death.tips
:scheme: https
:path: /
pragma: no-cache
cache-control: no-cache
upgrade-insecure-requests: 1
user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3236.0 Safari/537.36
accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
accept-encoding: gzip, deflate, br
accept-language: en-US,en;q=0.9
--> parent_stream_id = 0
--> source_dependency = 3060 (HTTP_STREAM_JOB)
--> stream_id = 1
--> weight = 256
t=304310 [st=21] HTTP2_SESSION_RECV_SETTINGS
t=304310 [st=21] HTTP2_SESSION_SEND_SETTINGS_ACK
t=304313 [st=24] HTTP2_SESSION_RECV_SETTINGS_ACK
t=304336 [st=47] HTTP2_SESSION_RECV_PUSH_PROMISE
--> :scheme: https
:authority: death.tips
:path: /index.css
:method: GET
--> id = 1
--> promised_stream_id = 2
t=304336 [st=47] HTTP2_STREAM_SEND_PRIORITY
--> exclusive = true
--> parent_stream_id = 1
--> stream_id = 2
--> weight = 110
t=304336 [st=47] HTTP2_SESSION_RECV_PUSH_PROMISE
--> :scheme: https
:authority: death.tips
:path: /index.js
:method: GET
--> id = 1
--> promised_stream_id = 4
t=304336 [st=47] HTTP2_STREAM_SEND_PRIORITY
--> exclusive = true
--> parent_stream_id = 2
--> stream_id = 4
--> weight = 110
t=304336 [st=47] HTTP2_SESSION_RECV_PUSH_PROMISE
--> :scheme: https
:authority: death.tips
:path: /routes.js
:method: GET
--> id = 1
--> promised_stream_id = 6
t=304336 [st=47] HTTP2_STREAM_SEND_PRIORITY
--> exclusive = true
--> parent_stream_id = 4
--> stream_id = 6
--> weight = 110
t=304336 [st=47] HTTP2_SESSION_RECV_HEADERS
--> fin = false
--> :status: 200
cache-control: public, max-age=0
content-encoding: deflate
content-length: 388
content-type: text/html; charset=utf-8
date: Mon, 09 Oct 2017 14:49:24 GMT
etag: "c3QDLn1lTsAqsErFvMgM3bEsUsY="
last-modified: Mon, 09 Oct 2017 14:43:24 GMT
--> stream_id = 1
t=304336 [st=47] HTTP2_SESSION_RECV_HEADERS
--> fin = false
--> :status: 200
cache-control: public, max-age=0
content-encoding: deflate
content-length: 88
content-type: text/css
date: Mon, 09 Oct 2017 14:49:24 GMT
etag: "/qkigeCvJgEE+0+5YhHLgByhKL0="
last-modified: Mon, 09 Oct 2017 14:43:24 GMT
--> stream_id = 2
t=304336 [st=47] HTTP2_SESSION_RECV_HEADERS
--> fin = false
--> :status: 200
cache-control: public, max-age=0
content-encoding: deflate
content-length: 60
content-type: text/javascript
date: Mon, 09 Oct 2017 14:49:24 GMT
etag: "/+cUWoFWkafsB6vSI5wBuB7v4Tk="
last-modified: Mon, 09 Oct 2017 14:43:24 GMT
--> stream_id = 4
t=304336 [st=47] HTTP2_SESSION_RECV_HEADERS
--> fin = false
--> :status: 200
cache-control: public, max-age=0
content-encoding: deflate
content-length: 64
content-type: text/javascript
date: Mon, 09 Oct 2017 14:49:24 GMT
etag: "2ZM3pEXqn9z1d5tkBr2x5kdHsGk="
last-modified: Mon, 09 Oct 2017 14:43:24 GMT
--> stream_id = 6
t=304336 [st=47] HTTP2_SESSION_RECV_DATA
--> fin = false
--> size = 388
--> stream_id = 1
t=304336 [st=47] HTTP2_SESSION_UPDATE_RECV_WINDOW
--> delta = -388
--> window_size = 15728252
t=304336 [st=47] HTTP2_SESSION_RECV_DATA
--> fin = true
--> size = 0
--> stream_id = 1
t=304336 [st=47] HTTP2_SESSION_RECV_DATA
--> fin = false
--> size = 88
--> stream_id = 2
t=304336 [st=47] HTTP2_SESSION_UPDATE_RECV_WINDOW
--> delta = -88
--> window_size = 15728164
t=304336 [st=47] HTTP2_SESSION_RECV_DATA
--> fin = true
--> size = 0
--> stream_id = 2
t=304336 [st=47] HTTP2_SESSION_RECV_DATA
--> fin = false
--> size = 60
--> stream_id = 4
t=304336 [st=47] HTTP2_SESSION_UPDATE_RECV_WINDOW
--> delta = -60
--> window_size = 15728104
t=304336 [st=47] HTTP2_SESSION_RECV_DATA
--> fin = true
--> size = 0
--> stream_id = 4
t=304336 [st=47] HTTP2_SESSION_RECV_DATA
--> fin = false
--> size = 64
--> stream_id = 6
t=304336 [st=47] HTTP2_SESSION_UPDATE_RECV_WINDOW
--> delta = -64
--> window_size = 15728040
t=304336 [st=47] HTTP2_SESSION_RECV_DATA
--> fin = true
--> size = 0
--> stream_id = 6
t=304337 [st=48] HTTP2_SESSION_UPDATE_RECV_WINDOW
--> delta = 388
--> window_size = 15728428
t=304342 [st=53] HTTP2_STREAM_ADOPTED_PUSH_STREAM
--> stream_id = 2
--> url = "https://death.tips/index.css"
t=304343 [st=54] HTTP2_SESSION_UPDATE_RECV_WINDOW
--> delta = 88
--> window_size = 15728516
Second Req (/index.js)
3085: HTTP2_SESSION
death.tips:443 (DIRECT)
Start Time: 2017-10-09 10:49:24.694
t=304386 [st= 0] +HTTP2_SESSION [dt=?]
--> host = "death.tips:443"
--> proxy = "DIRECT"
t=304386 [st= 0] HTTP2_SESSION_INITIALIZED
--> protocol = "h2"
--> source_dependency = 3084 (SOCKET)
t=304386 [st= 0] HTTP2_SESSION_SEND_SETTINGS
--> settings = ["[id:1 (SETTINGS_HEADER_TABLE_SIZE) value:65536]","[id:3 (SETTINGS_MAX_CONCURRENT_STREAMS) value:1000]","[id:4 (SETTINGS_INITIAL_WINDOW_SIZE) value:6291456]"]
t=304386 [st= 0] HTTP2_SESSION_UPDATE_RECV_WINDOW
--> delta = 15663105
--> window_size = 15728640
t=304386 [st= 0] HTTP2_SESSION_SEND_WINDOW_UPDATE
--> delta = 15663105
--> stream_id = 0
t=304386 [st= 0] HTTP2_SESSION_SEND_HEADERS
--> exclusive = true
--> fin = true
--> has_priority = true
--> :method: GET
:authority: death.tips
:scheme: https
:path: /index.js
pragma: no-cache
cache-control: no-cache
origin: https://death.tips
user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3236.0 Safari/537.36
accept: */*
referer: https://death.tips/
accept-encoding: gzip, deflate, br
accept-language: en-US,en;q=0.9
--> parent_stream_id = 0
--> source_dependency = 3080 (HTTP_STREAM_JOB)
--> stream_id = 1
--> weight = 220
t=304405 [st=19] HTTP2_SESSION_RECV_SETTINGS
t=304405 [st=19] HTTP2_SESSION_SEND_SETTINGS_ACK
t=304409 [st=23] HTTP2_SESSION_RECV_SETTINGS_ACK
t=304409 [st=23] HTTP2_SESSION_RECV_PUSH_PROMISE
--> :scheme: https
:authority: death.tips
:path: /routes.js
:method: GET
--> id = 1
--> promised_stream_id = 2
t=304409 [st=23] HTTP2_STREAM_SEND_PRIORITY
--> exclusive = true
--> parent_stream_id = 1
--> stream_id = 2
--> weight = 110
t=304409 [st=23] HTTP2_SESSION_RECV_HEADERS
--> fin = false
--> :status: 200
cache-control: public, max-age=0
content-encoding: deflate
content-length: 60
content-type: text/javascript
date: Mon, 09 Oct 2017 14:49:24 GMT
etag: "/+cUWoFWkafsB6vSI5wBuB7v4Tk="
last-modified: Mon, 09 Oct 2017 14:43:24 GMT
--> stream_id = 1
t=304409 [st=23] HTTP2_SESSION_RECV_HEADERS
--> fin = false
--> :status: 200
cache-control: public, max-age=0
content-encoding: deflate
content-length: 64
content-type: text/javascript
date: Mon, 09 Oct 2017 14:49:24 GMT
etag: "2ZM3pEXqn9z1d5tkBr2x5kdHsGk="
last-modified: Mon, 09 Oct 2017 14:43:24 GMT
--> stream_id = 2
t=304409 [st=23] HTTP2_SESSION_RECV_DATA
--> fin = false
--> size = 60
--> stream_id = 1
t=304409 [st=23] HTTP2_SESSION_UPDATE_RECV_WINDOW
--> delta = -60
--> window_size = 15728580
t=304409 [st=23] HTTP2_SESSION_RECV_DATA
--> fin = true
--> size = 0
--> stream_id = 1
t=304409 [st=23] HTTP2_SESSION_RECV_DATA
--> fin = false
--> size = 64
--> stream_id = 2
t=304409 [st=23] HTTP2_SESSION_UPDATE_RECV_WINDOW
--> delta = -64
--> window_size = 15728516
t=304409 [st=23] HTTP2_SESSION_RECV_DATA
--> fin = true
--> size = 0
--> stream_id = 2
t=304410 [st=24] HTTP2_SESSION_UPDATE_RECV_WINDOW
--> delta = 60
--> window_size = 15728576
t=304412 [st=26] HTTP2_STREAM_ADOPTED_PUSH_STREAM
--> stream_id = 2
--> url = "https://death.tips/routes.js"
t=304413 [st=27] HTTP2_SESSION_UPDATE_RECV_WINDOW
--> delta = 64
--> window_size = 15728640
This was quite a mystery!
The issue is that — well, I’m not gonna be able to explain this well, but my shallow understanding is that documents are requested "with credentials", but <script type="module"> triggers, by default, a "no credentials" request. The push promise for the script is "with credentials" by association, but never the twain shall meet. So the browser must make a new request because the push promise "doesn’t count". And there is a solution:
<script type="module" src="/index.js" crossorigin="use-credentials">
I would never have thought to use a "crossorigin" attribute to fetch a resource on the same site, but there it is. Push gets adopted, and my little experiment just got twice as fast.
Here’s the transcript of the whole conversation in #whatwg:
[7:35pm] <bathos> I’ve got a question about interactions between module
loading and HTTP2 that’s had me scratching my head for a few days — is
that something appropriate to ask about here?
[7:37pm] <jyasskin> bathos: Yes.
[7:39pm] <bathos> Cool. I’ve been experimenting with serving resources using
HTTP2 push — assemble a dep graph in advance and follow through on
requests by provisioning their known dependencies as push promises. This
works great on the whole, but there’s a quirk I’ve observed that seems to
be related specifically to ES module "entrypoints".
[7:40pm] <bathos> I asked about it on SO, so there’s a bit of detail in the
question and comments there: https://stackoverflow.com/questions/46642569/http2-push-and-native-es-modules-entry-module-push-is-ignored
[7:40pm] <bathos> The gist though:
[7:41pm] <bathos> Given a request for a document which contains
<script type="module" src="something">, and an http2 session which
includes a push promise for "something", the "something" push is never
adopted. Instead, the browser makes a fresh request for it.
[7:41pm] <jyasskin> Domenic: ^
[7:42pm] <bathos> Dependencies imported _in_ ES are adopted.
[7:42pm] <jyasskin> bathos: I'm not an expert here, but your question
reminds me of the with-vs-no-credentials problem in
https://github.com/whatwg/fetch/issues/354.
[7:42pm] <bathos> And if I reference the same module in a different way in
the root document, e.g. a preload <link>, it is successfully adopted. It’s
peculiar to type="module"
[7:43pm] <bathos> oh, interesting
[7:43pm] <jyasskin> Apologies if I've just sent you on a wild goose chase.
[7:44pm] <bathos> I have been on a lot for the last two days haha! Since
HTTP2 is still pretty mysterious to me, it’d been hard to rule out the
possibility that I’m doing something weird there, though I’m pretty sure
at this point that I’m not.
[7:52pm] <bathos> jyasskin you genius!
[7:53pm] <jyasskin> s/genius/pattern-matcher/ :)
[7:53pm] <bathos> crossorigin="use-credentials" in the doc actually makes
the module push promise get adopted
[7:54pm] <bathos> I never would have thought to try "crossorigin" on a file
on the same host haha
The browser activity is the following:
send request (stream=1)
receive push promise for /index.css (stream=2)
receive push promise for /index.js (stream=4)
receive push promise for /routes.js (stream=6)
receive headers for stream=1
receive headers for stream=2
receive headers for stream=4
receive headers for stream=6
receive data for stream=1 (388+0 bytes)
receive data for stream=2 (88+0 bytes)
receive data for stream=4 (60+0 bytes)
receive data for stream=6 (64+0 bytes)
My interpretation is that the browser receives the whole body for the primary request (stream=1) before it receives the whole body for the pushed resources.
I'm guess internally the browser starts parsing the HTML, figure out it needs /index.js, find that it is not yet arrived although it has been promised, and therefore it issues a request for it.
The browser probably needs /index.css later than it needs /index.js, and by the time it needs the CSS it has already arrived to the browser as a pushed resource, and that would explain why /index.css is used from the push cache.
If you can control when the resources are written to the network, try to send the whole body of /index.js before sending the HTML body. That should make the browser aware that index.js is fully available in the push cache and use it from there, rather than requesting it anew.
A final note that the push cache implementation in Chrome has varied greatly over the years/months, so what could be true today may not hold in the future.

Gmail API removes message part

When I send a message with attachment using the Gmail API, the recipient receives the message without the attachment.
What is strange though is that:
1: in the sent folder of the sender, I do see the attachment properly
2: if I send to myself, both message are fine (in sent folder and in inbox folder)
3: if I use with GMail SMTP with the same raw message, it works fine
4: if I use a 3rd party SMTP with the same raw message, it works fine.
Point number 1+2 super puzzling.
Here is the source of the original message in the sent folder:
Received: from 13936824666 named unknown by gmailapi.google.com with HTTPREST; Wed, 25 Jan 2017 18:44:30 -0500
Date: Wed, 25 Jan 2017 18:44:30 -0500
From: Jeremy Chatelaine <source#gmail.com>
To: Jeremy <target#domain.com>
Message-Id: <CABX8Avad0vTtu8=jotRD5HM1r0My-ZKeV7RFRo0TmTxf5PNd0g#mail.gmail.com>
Subject: Export
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5889385be5066_a133fd0f785e20837629"; charset=UTF-8
Content-Transfer-Encoding: 7bit
----==_mimepart_5889385be5066_a133fd0f785e20837629
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Please find attached the message
----==_mimepart_5889385be5066_a133fd0f785e20837629
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit
Please find attached the message
----==_mimepart_5889385be5066_a133fd0f785e20837629
Content-Type: text/csv; charset=UTF-8; filename=export.csv
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename=export.csv
Content-ID: <5889385be6fd7_a133fd0f785e20837735#jeremy.mail>
Some text...
----==_mimepart_5889385be5066_a133fd0f785e20837629--
Here is the source of the original message in the recipient inbox folder:
Delivered-To: target#domain.com
Received: by 10.55.110.193 with SMTP id j184csp1999707qkc;
Wed, 25 Jan 2017 16:30:42 -0800 (PST)
X-Received: by 10.107.34.213 with SMTP id i204mr540101ioi.203.1485390642385;
Wed, 25 Jan 2017 16:30:42 -0800 (PST)
Return-Path: <source#domain.com>
Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com. [2607:f8b0:4001:c0b::22b])
by mx.google.com with ESMTPS id 88si336719ioq.54.2017.01.25.16.30.42
for <target#domain.com>
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Wed, 25 Jan 2017 16:30:42 -0800 (PST)
Received-SPF: pass (google.com: domain of source#domain.com designates 2607:f8b0:4001:c0b::22b as permitted sender) client-ip=2607:f8b0:4001:c0b::22b;
Authentication-Results: mx.google.com;
dkim=pass header.i=#domain.com;
spf=pass (google.com: domain of source#domain.com designates 2607:f8b0:4001:c0b::22b as permitted sender) smtp.mailfrom=source#domain.com
Received: by mail-it0-x22b.google.com with SMTP id 203so119411500ith.0
for <target#domain.com>; Wed, 25 Jan 2017 16:30:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=domain.com; s=domain;
h=from:mime-version:date:message-id:subject:to;
bh=wx26/V0bJk9VItDp3TAvKl28UAn7IRQq4NITJZDM+Co=;
b=L3KTzPTCoIJUfAacuJy+PE8jHnY9iwGuXUWSpZzneRs5bvMysigSMyPGn1YicyIvQ6
d/LvbEJPlsu+S0zElhIVPITjAmXKDKNIKwLQDHpkcKnnI3btBUrENN923fMtS1fDdHyV
3At0QenKrb34uQqYYoHtX2WU4nyYrISbYKL62=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:from:mime-version:date:message-id:subject:to;
bh=wx26/V0bJk9VItDp3TAvKl28UAn7IRQq4NITJZDM+Co=;
b=tGPSHjI3iRzjrI0jGHVX76uTw7OXYC4B2bP0qQKgQotBWru+Pn5Ci9A1Qop9oGN1Ys
fnxCgLOLG8ZJU165ODBNX1DGjPa8ud9SWg18FTsxIjNw9qTr1yJqbWr0LToJi7HdQUr8
7Aaiqil7PbPUf5SdxLCqwBNf660Rn9Sd/ADZeT1Bc2+iYQcizjiK/rOPPX+X1ZndvqxP
Ok3Ac2yyIWxi+m4xaPEztcF4JXFZDlJWFdclUDv4s5Jdc0eb1HmB5d2r1qroGLo5MTjd
d7jO1nRsKTO5I9I69p9AgC+LpDiWBxgzZMBVsU6vVpeZ03/pCroyk9DHDUAjn3ijtlFh
O2vw==
X-Gm-Message-State: AIkVDXJo2tPJlkHkthgEjnxYp7vz5Rfpn91pWCS7zEurkSiDhJtyzLpUoSDORq37K/7ATCRSyLAypKIYrdYwEiL2
X-Received: by 10.36.84.148 with SMTP id t142mr20263701ita.90.1485390641934; Wed, 25 Jan 2017 16:30:41 -0800 (PST)
Received: from 13936824667 named unknown by gmailapi.google.com with HTTPREST; Wed, 25 Jan 2017 19:30:41 -0500
From: Jeremy Chatelaine <source#domain.com>
Mime-Version: 1.0
Date: Wed, 25 Jan 2017 19:30:41 -0500
Message-ID: <CABK5xHonVstaJHWHfvBJFF1BK5Y0B8NJsAJTPFokPNAUcawhGA#mail.gmail.com>
Subject: Export
To: Jeremy <target#domain.com>
Content-Type: multipart/alternative; boundary=001a1143a6cc90c9040546f4753f
--001a1143a6cc90c9040546f4753f
Content-Type: text/plain; charset=UTF-8
Please find attached your requested export
--001a1143a6cc90c9040546f4753f
Content-Type: text/html; charset=UTF-8
Please find attached your requested export
--001a1143a6cc90c9040546f4753f--
As you can see, the mime part where I had my text attachment vanished.
Here is how the message is produced (cut for clarity)
msg = Mail.new
html_part = Mail::Part.new do
content_type 'text/html; charset=UTF-8'
body html_body
end
msg.html_part = html_part
new_text = plan_text
text_part = Mail::Part.new do
body new_text
end
msg.text_part = text_part
file_paths.each do |file_path|
msg.add_file(file_path)
# I also tried like that, same result
#open(file_path) do |file|
# msg.attachments[file_path] = file.read
#end
end
raw_message = msg.to_s
Here is how I send with the gmail api
client = Google::APIClient.new(:application_name => "app", :application_version => "1")
client.authorization.client_id = "someverylongnumbers.apps.googleusercontent.com"
client.authorization.client_secret = "morerandomletters"
client.authorization.access_token = token
client.authorization.scope = [
"https://www.googleapis.com/auth/gmail.modify"
]
gmail_api = client.discovered_api('gmail', 'v1') # https://www.googleapis.com/auth/gmail.modify
result = client.execute(
:api_method => gmail_api.users.messages.to_h['gmail.users.messages.send'],
:parameters => {
'userId' => "me"
},
:body_object => {
'raw' => Base64.urlsafe_encode64(raw_message)
}
)
What is wrong with this?

Understanding Lync client multipart SDP with MIME

Could anybody give me some pure Insight how to create multipart sdp and what is the meaning of the all attribute of this given SDP.
Content-Type: multipart/alternative;boundary="----=_NextPart_000_001B_01CDC5AC.EC1E2DE0"
ms-routing-phase:from-uri-routing-done
------=_NextPart_000_001B_01CDC5AC.EC1E2DE0
Content-Type: application/sdp
Content-Transfer-Encoding: 7bit
Content-ID: <67c36ea12e87436e8fd1133d26194444#afdgs.com>
Content-Dis; handling=optional; ms-proxy-2007fallback
v=0
o=- 0 0 IN IP4 192.168.0.179
s=session
c=IN IP4 192.168.0.179
b=CT:99980
t=0 0
m=audio 19384 RTP/AVP 114 9 112 111 0 8 116 115 4 97 13 118 101
a=candidate:oKpwKDjMnfFmkSeXlIgoUEYW0BiriMilFQluFogmIQ8 1 XJoleCXuzzNJHAdN0G5MHg UDP 0.830 192.168.0.179 19384
a=candidate:oKpwKDjMnfFmkSeXlIgoUEYW0BiriMilFQluFogmIQ8 2 XJoleCXuzzNJHAdN0G5MHg UDP 0.830 192.168.0.179 19385
a=cryptoscale:1 client AES_CM_128_HMAC_SHA1_80 inline:28zhxoLlrww36J41bGxjePNf0ft/BbQkHXd2Pwf2|2^31|1:1
a=crypto:2 AES_CM_128_HMAC_SHA1_80 inline:EHIG0MBaCja1hyD1kJJvm3A8Ld8sIbCyeY26J5TI|2^31|1:1
a=crypto:3 AES_CM_128_HMAC_SHA1_80 inline:4y2YFeVNzH/rdIrbkSD+kMMFYP5OlccmnfBeELrW|2^31
a=maxptime:200
Specially the encrypted value of a=candidate: , How to decrypt and create it.
Is there any doc or rfc please indicate.
Thanks.
The answer is that it is an old ICE candidate and SDP ,which is supported by Lync client with
new ICE candidate support.So it is multipart which enable both old and new ICE support for a single client.(If the client have both ICE support)

Different source code results from different clients(gmail,outlook 2010, thunderbird)

I am trying to send email from my asp.net mvc 3 application with actionmailer mvc
I sent it to my gmail account and veiw the source
Delivered-To: mygmail#gmail.com
Received: by 10.204.10.11 with SMTP id n11cs48097bkn;
Mon, 20 Jun 2011 09:48:33 -0700 (PDT)
Received: by 10.150.209.3 with SMTP id h3mr5801335ybg.353.1308588512444;
Mon, 20 Jun 2011 09:48:32 -0700 (PDT)
Return-Path: <noreply#mysite.com>
Received: from mail.myhostserver.com (mail.myhostserver.com. [ip address here])
by mx.google.com with ESMTP id r38si5731169yba.61.2011.06.20.19.42.41;
Mon, 20 Jun 2011 09:48:32 -0700 (PDT)
Received-SPF: fail (google.com: domain of noreply#myhostserver.com does not designate 216.41.41.125 as permitted sender) client-ip=216.11.21.125;
Authentication-Results: mx.google.com; spf=hardfail (google.com: domain of noreply#myhostserver.com does not designate 216.41.21.125 as permitted sender) smtp.mail=noreply#myhostserver.com
Message-Id: <4dff79e0.2645960a.472d.49efSMTPIN_ADDED#mx.google.com>
Received: from myhostserver (myhostserver.com [216.14.12.122]) by mail.myhostserver.com with SMTP;
Mon, 20 Jun 2011 11:47:29 -0500
MIME-Version: 1.0
From: noreply#myhostserver.com
To: mygmail#gmail.com
Date: 20 Jun 2011 09:47:30 -0700
Subject: Test Email
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
<html>=0D=0A<head>=0D=0A <title></title>=0D=0A <meta http-e=
quiv=3D"Content-Type" content=3D"text/html; charset=3DUTF-8" />=0D=0A=
</head>=0D=0A<body style=3D"font-size: 1em;">=0D=0A <img s=
rc=3D"http://www.my.site.com/Content/Images/si=
telogo.png" alt=3D"My Logo" style=3D"width: 231=
px; height: 63px;" />=0D=0A=0D=0A <div>=0D=0A =0D=0A<h2=
>TestEmail</h2>=0D=0A=0D=0A=0D=0A </div>=0D=0A <div>My Mai=
ler Footer</div>=0D=0A</body>=0D=0A=0D=0A</html>=0D=0A
*note server names, my email address, ip's been changed.
I viewed the same message through thunderbird(so it still the same gmail address) and I got the same looking html with all those funny characters.
Now I sent it to another email address that is setup with exchange and viewed through outlook 2010.
<html>
<head>
<title></title>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
</head>
<body style="font-size: 1em;">
<img src="http://mysite.com/Content/Images/sitelogo.png" alt="mysite Logo" style="width: 231px; height: 63px;" />
<div>
<h2>TestEmail</h2>
</div>
<div> Mailer Footer</div>
</body>
</html>
Why does it look normal in outlook 2010 but not gmail/thunderbird?
Edit
Here is one from staples
Delivered-To: myemailk#gmail.com
Received: by 14.227.5.217 with SMTP id w57cs20187wes;
Wed, 22 Jun 2011 09:56:05 -0700 (PDT)
Received: by 11.132.41.10 with SMTP id v10mr221945wfv.185.1308761763097;
Wed, 22 Jun 2011 09:56:03 -0700 (PDT)
Return-Path: <bo-bwff20ebg7m4p3au641sjqcgt5vvs6#b.e.staples.ca>
Received: from mta734.e.staples.com (mta734.e.staples.com [38.117.148.114])
by mx.google.com with SMTP id m3si4122907icx.82.2011.06.44.09.50.02;
Wed, 22 Jun 2011 09:56:03 -0700 (PDT)
Received-SPF: pass (google.com: domain of bo-bwff20ebg7m4p3au641sjqcgt5vvs6#b.e.staples.ca designates 38.137.148.134 as permitted sender) client-ip=34.107.118.125;
DomainKey-Status: good (test mode)
Authentication-Results: mx.google.com; spf=pass (google.com: domain of bo-bwff20ebg7m4p3au641sjqcgt5vvs6#b.e.staples.ca designates 38.117.148.122 as permitted sender) smtp.mail=bo-bwff20ebg7m4p3au641sjqcgt5vvs6#b.e.staples.ca; domainkeys=pass (test mode) header.From=staplescanada#e.staples.ca
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
s=200505; d=e.staples.ca;
b=Ea8rCw0vzifMnnDucyEP7U7dnIz1GZ80sb9XKhvzHr3Qa+iIAQjtX0PT+W0HrNTU2hPumPnz1GOC1irFMNvx8eYPeLqJvk1l6BXms4VQVPMsAe/a6RYM50vVbxWOq0msmtMzVx5YhQbMhMl9XqlhR/czwlzJ0GJjbtoMbEHwU0Y=;
h=Date:Message-ID:List-Unsubscribe:From:To:Subject:MIME-Version:Reply-To:Content-type;
Date: Wed, 22 Jun 2011 16:56:24 -0000
Message-ID: <bwff20ebg7m4p3au641sjqcgt5vvs6.14705389806.671#mta734.e.staples.ca>
List-Unsubscribe: <mailto:rm-0bwff20ebg7m4p3au641sjqcgt5vvs6#e.staples.ca>
From: "Staples" <staplescanada#e.staples.ca>
To: myemailk#gmail.com
Subject: Summer Hot Buys!
MIME-Version: 1.0
Reply-To: "Staples" <support-bwff20ebg7m4p3au641sjqcgt5vvs6#e.staples.ca>
Content-type: multipart/alternative; boundary="=bwff20ebg7m4p3au641sjqcgt5vvs6"
--=bwff20ebg7m4p3au641sjqcgt5vvs6
Content-Type: text/plain; charset="iso-8859-1"
Content-transfer-encoding: 8bit
I am not sure why it says text/plain since it is using html.
The funny characters are just the way the e-mail body is encoded to avoid getting mangled in transport, as the content-transfer-encoding header in the envelope specifies. Outlook shows you the decoded message source, but still the source, whereas GMail and Thunderbird give you a "raw" view of the source. In this case, the encoding used is called quoted-printable.

Resources