I'd like to propose a pair of new TS APIs below.
TSReturnCode TSHttpTxnVerifiedAddrSet(TSHttpTxn txnp, const struct sockaddr
*addr);
TSReturnCode TSHttpTxnVerifiedAddrGet(TSHttpTxn txnp, const struct sockaddr
**addr);
The motivation is to enable plugins to provide client's "real" IP address
for A
Description:
Apache Traffic Server has an ACL issue, and also has a vulnerability in ESI
processing
CVE:
CVE-2025-31698 - Client IP address from PROXY protocol is not used for ACL
CVE-2025-49763 - Remote DoS via memory exhaustion in ESI Plugin
Reported By:
Masakazu Kitajo (CVE-2025-31698)
Yohann
+1 Built and tested on Debian 13
-- Masakazu
On Mon, Jun 16, 2025 at 7:30 PM Chris McFarlen wrote:
> [VOTE] Release Apache Traffic Server 10.0.5 (RC0)
> I've prepared a release for 10.0.6. The release notes are available at:
>
> https://github.com/apache/trafficserver/milestone/88?clos
+1 Tested on Debian 13
-- Masakazu
On Mon, Jun 16, 2025 at 3:56 PM Evan Zelkowitz wrote:
> I've prepared a release for 9.2.11. The release notes are available at:
>
> https://github.com/apache/trafficserver/milestone/87?closed=1
>
> https://docs.trafficserver.apache.org/en/latest/release-notes
+1 for removing it for 11.0.
Apparently the operator is from the initial commit. We should have
deprecated the operator when we added set-config operator.
-- Masakazu
On Wed, May 7, 2025 at 4:18 PM Leif Hedstrom wrote:
> Well, dangit, it turns out, you could use this functionality if you
> fig
I wonder if the max number of connections should be limited by ATS. I guess
it could be done by iptables if the connections are going to be just
closed. It'd be even better because TCP handshake would not be completed.
It would be a nice addition if iptables or firewalls cannot handle QUIC
connecti
Oh, I just realized that the setting for the max number of connections
already exists and just the exempt setting is new... but I'm still not sure
if we should invest in the setting because of the questions on my previous
email.
-- Masakazu
On Thu, Apr 17, 2025 at 6:41 PM Masakazu Kitajo
+1 Built and tested on Debian 13
-- Masakazu
On Tue, Apr 1, 2025 at 2:38 PM Evan Zelkowitz wrote:
> +1
>
> Built and tested on Rocky 9
>
> On Tue, Apr 1, 2025 at 12:42 PM Evan Zelkowitz
> wrote:
>
>> I've prepared a release for 9.2.10. The release notes are available at:
>>
>> https://github.c
Description:
ATS is vulnerable to request smuggling via chunked messages
CVE:
CVE-2024-53868 - Chunked message body allows request smuggling
Reported By:
Jeppe Bonde Weikop (CVE-2024-53868)
Vendor:
The Apache Software Foundation
Version Affected:
ATS 9.0.0 to 9.2.9
ATS 10.0.0 to 10.0.4
Mitigat
+1 Built and tested on Debian 13
-- Masakazu
On Tue, Apr 1, 2025 at 1:07 PM Chris McFarlen wrote:
> I've prepared a release for 10.0.5. The release notes are available at:
>
> https://github.com/apache/trafficserver/milestone/86?closed=1
>
> https://docs.trafficserver.apache.org/en/latest/re
Description:
ATS is vulnerable to malformed requests, and also has ACL issues
CVE:
CVE-2024-38311 - Request smuggling via pipelining after a chunked message
body
CVE-2024-56195 - Intercept plugins are not access controlled
CVE-2024-56196 - ACL is not fully compatible with older versions
CVE-2024-5
+1 Built and tested on Debian 13
-- Masakazu
On Tue, Mar 4, 2025 at 3:03 PM Chris McFarlen wrote:
> I've prepared a release for 10.0.4. The release notes are available at:
>
> https://github.com/apache/trafficserver/milestone/82?closed=1
>
> https://docs.trafficserver.apache.org/en/latest/rele
+1 Built and tested on Debian Trixi
-- Masakazu
On Tue, Mar 4, 2025 at 1:09 PM Evan Zelkowitz wrote:
> I've prepared a release for 9.2.9. The release notes are available at:
>
> https://github.com/apache/trafficserver/milestone/83?closed=1
>
> https://docs.trafficserver.apache.org/en/latest/rel
se PROXY (all upper
> > case) instead of PP, which is how it’s spelled.
> >
> > — Leif
> >
> > On Sat, Feb 8, 2025 at 20:03 Brian Neradt
> wrote:
> >
> >> +1
> >>
> >> My preference would be to spell out ProxyProtocol in the API instead of
&
Hi,
I'd like to propose a new TS API to access information from PROXY protocol.
ATS supports PROXY protocol, which carries connection information between a
client and a LB (basically the 5-tuple). And I recently added the support
for PROXY protocol version 2 TLV (Type-Length-Value) fields, which
+1 Built and tested on Debian 13
Masakazu
On Thu, Nov 21, 2024 at 2:57 PM Evan Zelkowitz wrote:
> I've prepared a release for 9.2.7. The release notes are available at:
>
> https://github.com/apache/trafficserver/milestone/79?closed=1
>
> https://docs.trafficserver.apache.org/en/latest/release-
(CVE-2024-38479)
Masakazu Kitajo (CVE-2024-50305)
Jeffrey BENCTEUX (CVE-2024-50306)
Vendor:
The Apache Software Foundation
Version Affected:
ATS 9.0.0 to 9.2.5 (CVE-2024-38479, CVE-2024-50305, CVE-2024-50306)
ATS 10.0.0 to 10.0.1 (CVE-2024-50306)
Mitigation:
9.x users should upgrade to 9.2.6 or
Description:
Apache Traffic Server is vulnerable to request smuggling and DoS
CVE:
CVE-2023-38522 - Incomplete field name check allows request smuggling
CVE-2024-35161 - Incomplete check for chunked trailer section allows
request smuggling
CVE-2024-35296 - Invalid Accept-Encoding can force forward
+1, built and tested on Debian 11, also verified the checksum.
On Tue, Jul 23, 2024 at 4:59 PM Evan Zelkowitz wrote:
> I've prepared a release for 8.1.11. The release notes are available at:
>
> https://github.com/apache/trafficserver/milestone/76?closed=1
>
>
> or for a brief ChangeLog
+1, built and tested on Debian 11, also verified the checksum.
On Tue, Jul 23, 2024 at 4:37 PM Bryan Call wrote:
> I've prepared a release for 9.2.5. The release notes are available at:
>
> https://github.com/apache/trafficserver/milestone/75?closed=1
>
>
> or for a brief ChangeLog:
>
>
Hi all,
Several committers discussed the removal of TSUrlHttpParamsGet/Set, and we
agreed to remove the APIs on version 10.0.
Here's the summary:
- There were no objections to removing the APIs - the main topics were when
and how
- The options we had were:
a) Make changes to the API for conveni
One week of silence. I assume the proposal was accepted.
I made a PR for this change.
https://github.com/apache/trafficserver/pull/11519
Thanks,
Masakazu
On Mon, Jul 1, 2024 at 10:21 PM Masakazu Kitajo wrote:
> Hi all,
>
> I'd like to propose these two changes bel
Hi all,
I'd like to propose these two changes below:
- Remove TSUrlHttpParamsGet/Set
- Remove special treatment for the "params" segment (not query parameters,
see below)
- Change TSUrlPathGet to include the "params" segment (as the result of the
removal of special treatment above)
RFC 1808 defi
t the end it was deemed too complicated, and a simple flag set by an
> api might be easier for the plugins to use.
>
> Do we have a test for that feature mentioned in the docs?
>
>
> Regards,
> Fei Deng
>
> Sent from my iPhone
>
>
> On Mon, Jun 1
at 8:32 PM Masakazu Kitajo wrote:
> Purposefully? Where did it happen? I'd say it was broken. We have that use
> case and need a FIX.
>
> Masakazu
>
> On Mon, Jun 17, 2024 at 6:47 PM Fei Deng wrote:
>
>> Actually it’s not possible by setting the “Connection: c
ith all the discussions it
> looks like that functionality was taken out purposefully.
>
> Regards,
> Fei Deng
>
> Sent from my iPhone
>
>
> On Mon, Jun 17, 2024 at 8:42 PM Masakazu Kitajo wrote:
>
> > It has been possible by setting "Connection: Close" hea
It has been possible by setting "Connection: Close" header, which means
that a server wants no more requests on the connection and wants to close
it.
If you want to close a connection on some conditions, you could check the
conditions and set the header by header_rewrite (or any plugins). And thos
n Mon, Jun 10, 2024 at 4:05 PM Brian Neradt wrote:
> After the refactor in this PR it is no longer needed:
> https://github.com/apache/trafficserver/pull/11432
>
> On Mon, Jun 10, 2024 at 3:53 PM Masakazu Kitajo wrote:
>
> > It doesn't look like we can remove
It doesn't look like we can remove the first parameter, but I guess I'm
missing something.
It's currently used in the API implementation like this:
HdrHeap *heap = ((HdrHeapSDKHandle *)bufp)->m_heap;
and heap is used like this:
mime_hdr_print(heap, mh, blk->end(), blk->write_avail(), &bufind
Like I said above, I think we should keep TS API minimal, because we cannot
change TS API casually. Once we add something, it's difficult to change or
remove it. I don't want to have much code with such constraints just for
convenience. That is why I've been very cautious about this (and any API
ad
hile incubating the wrapper as an independent
library.
On Wed, Apr 17, 2024 at 7:15 PM Walt Karas
wrote:
> The atscppapi was deprecated because it was buggy and had bad performance.
>
> On Wed, Apr 17, 2024 at 4:36 PM Masakazu Kitajo wrote:
>
> > I'm not saying any C++ wr
Walt Karas
wrote:
> The atscppapi had problems, but I don't agree that shows any C++ wrapper is
> bad. If we say we should not have an alternative C++ API, as well as a C
> API, that would imply we should not have a Lua API.
>
> On Wed, Apr 17, 2024 at 2:34 PM Masakazu Kitajo
We had a wrapper (the old TS CPP API), and we removed it. Why do we want to
have yet another wrapper now? What's the difference?
Also, I don't like to have libswoc stuff in the API. Using it internally is
ok because we can replace it anytime but having it as part of API is a huge
commitment.
A wr
+1 Built and tested on Debian 11. Confirmed the checksum is correct.
On Wed, Apr 3, 2024 at 10:03 AM Evan Zelkowitz wrote:
> I've prepared a release for 8.1.10. The release notes are available at:
>
> https://github.com/apache/trafficserver/milestone/71?closed=1
>
> or for a brief Chang
+1 Built and tested on Debian 11. Confirmed the checksum is correct.
On Wed, Apr 3, 2024 at 9:59 AM Bryan Call wrote:
> I've prepared a release for 9.2.4. The release notes are available at:
>
> https://github.com/apache/trafficserver/milestone/69?closed=1
>
> or for a brief ChangeLog:
I don't mind having the new API because it corresponds to the existing
setter API.
However, both APIs don't look very nice to me because the use case is
limited to handling very small objects. What if the object I'm trying to
get is video content? Does it allocate a big buffer for it?
I don't thi
Hi all,
I'd like to propose having the minimum "version" for BoringSSL for ATS 10.
Since BoringSSL does not have versions, obviously they do not follow
semantic versioning. We can only pick a random commit hash to draw a line,
and drawing the line does not guarantee anything in terms of compatibil
Hi all,
At the weekly ATS 10 meeting, the participants agreed to bump the minimum
OpenSSL version we support on ATS 10, and it's going to be 1.1.1. I'm
sending this email to make that an official decision.
The version bump is only for ATS 10 and later. There is no change for ATS 8
and 9.
I'm goi
I'd say get rid of it (when we delete the C++ API). I don't like having
that kind of general utility in our tree.
Masakazu
On Fri, Oct 27, 2023 at 7:20 AM Walt Karas
wrote:
>
> https://github.com/apache/trafficserver/blob/master/include/tscpp/api/noncopyable.h
>
> Given that the C++ API is depr
mental, I think we mostly decided to stop using this. In fact
> we should remove / move what’s left there IMO.
>
> — Leif
>
> > On Oct 25, 2023, at 14:10, Masakazu Kitajo wrote:
> >
> > Hi,
> >
> > I'd like to add TSHttpSsnInfoIntGet to TS API. T
Hi,
I'd like to add TSHttpSsnInfoIntGet to TS API. The API documentation is on
the PR below:
https://github.com/apache/trafficserver/pull/10627
We currently have a similar function, TSHttpTxnInfoIntGet, for
transactions, and the new API would be one for sessions. The function
signature is basical
Do we have a list of switches that are not supported / won't be supported ?
Are these supported?
--enable-event-tracker
--enable-fips
On Fri, Oct 20, 2023 at 10:09 AM Chris McFarlen wrote:
> Docs are planned and there will be a summit talk on using cmake. I plan
> to write docs as I am creatin
+1
It builds and test passes on Debian 11.
Confirmed the checksum.
On Mon, Oct 9, 2023 at 2:58 PM Bryan Call wrote:
> I've prepared a release for 9.2.3. The release notes are available at:
>
> https://github.com/apache/trafficserver/milestone/68?closed=1
>
>
> or for a brief ChangeLog:
>
> htt
+1
Builds and test passes on Debian11.
Confirmed the checksum as well.
On Mon, Oct 9, 2023 at 1:17 PM Evan Zelkowitz wrote:
> I've prepared a release for 8.1.9. The release notes are available at:
>
>
> https://github.com/apache/trafficserver/pulls?q=is:closed+is:pr+milestone:8.1.9
>
> or for
This is mainly for committers, but please take a look if you contribute
code, docs etc.
-- Forwarded message -
From: Roman Shaposhnik
Date: Tue, Aug 8, 2023 at 7:47 AM
Subject: Use of Generative AI tools
To:
Hi!
ASF's Legal Committee has issued the following guidance to
all co
nion here.
It's easy to determine whether CONNECT is used by using other functions.
Masakazu
On Fri, Sep 22, 2023 at 4:53 PM SUSAN HINRICHS
wrote:
> And Connect always confuses me. Let me test that scenario.
>
> On Fri, Sep 22, 2023, 4:24 PM Masakazu Kitajo wrote:
>
> > Hmm,
to add
> > this information to the vconn. Then I could pull the vconn from the txn
> > object to make this call.
> >
> > On Wed, Sep 13, 2023 at 12:19 PM Masakazu Kitajo
> > wrote:
> >
> >> Is it possible that the types of transactions on a connect
Is it possible that the types of transactions on a connection are
different? I suppose it's a type of connection or session.
- Masakazu
On Mon, Sep 11, 2023 at 5:22 PM SUSAN HINRICHS
wrote:
> I propose adding a new hook TS_HTTP_TUNNEL_START_HOOK. It triggers when a
> blind tunnel starts. A plug
Now we only support Quiche + BoringSSL for enabling QUIC on ATS.
The documentation is below. It was updated several weeks ago, so I hope it
works.
https://github.com/apache/trafficserver/wiki/HTTP-3-Documentation
And we have a script file to build ATS with QUIC support. This is for
convenience, a
Sounds reasonable.
Just one question. What would be the best places to store information like
"This origin server supports / prefers / breaks H2" ? We might want to
administratively disable H2-to-Origin for a particular origin server. We
currently don't use HostDB for it but I'm not sure where we
ing for it, which are better
> than anything I could write.
>
> I have no strong feelings about how things are spelled or abbreviated.
>
> On Sat, Sep 2, 2023 at 11:22 PM James Peach wrote:
>
> >
> > > On 2 Sep 2023, at 3:44 am, Masakazu Kitajo wrote:
> >
; Scenario 2. We use the RAII provided by Cleanup.h. If we find a better
> way, we change existing to use.
>
> Leaks followed by rewriting seems worse than no leaks followed by
> rewriting.
>
> On Thu, Aug 31, 2023 at 6:20 PM Masakazu Kitajo wrote:
>
> > I don't se
motorcycle. You
> don' t need it in the strictest sense, but you need it for a reasonable
> level of safety. You need RAII for a reasonable level of safety against
> resource leaks.
>
> On Thu, Aug 31, 2023 at 1:50 PM Masakazu Kitajo wrote:
>
> > I see your point, but I
and
> enhances (previously) C API.
>
> On Wed, Aug 30, 2023 at 1:15 PM Masakazu Kitajo wrote:
>
> > I wonder what should be part of TS API. There may be some exceptions, but
> > TS API basically provides things that can only be done on ATS core.
> >
> > Question for al
I wonder what should be part of TS API. There may be some exceptions, but
TS API basically provides things that can only be done on ATS core.
Question for all, would we want to have utilities as TS API?
-- Masakazu
On Tue, Aug 22, 2023 at 11:48 AM Walt Karas
wrote:
> See the PR https://github.
me coordination between plugin X
and Y.
On Sun, Aug 6, 2023 at 6:57 PM James Peach wrote:
>
>
> > On 4 Aug 2023, at 1:45 am, Masakazu Kitajo wrote:
> >
> > Hi,
> >
> > I'd like to propose a new flag for FetchSM that'd allow making HTTP
> > request
Hi,
I'd like to propose a new flag for FetchSM that'd allow making HTTP
requests for other servers without remap rules regardless of ATS
configuration (proxy.config.url_remap.remap_required).
The motivation is actually not enabling plugins to do the above. The code
on master uses FetchSM for OCSP
+1
Builds on Debian 11.6 and make check passes.
- Masakazu
On Wed, Aug 2, 2023 at 12:44 PM Evan Zelkowitz
wrote:
> I've prepared a release for 8.1.8. The release notes are available at:
>
>
>
> https://github.com/apache/trafficserver/pulls?q=is:closed+is:pr+milestone:8.1.8
>
> or for a brief
+1
Builds on Debian 11.6 (aarch64) and make check passes
On Wed, Aug 2, 2023 at 11:43 AM Randall Meyer
wrote:
> +1 Builds on macOS, make check passes
> On Wednesday, August 2, 2023 at 10:10:19 AM PDT, Bryan Call <
> bc...@apache.org> wrote:
>
> I've prepared a release for 9.2.2. The relea
> 3. Allow `$N` (capturing) support in the tunnel_route field as is
Does this mean we keep allowing "*.example.com" to be used for "
for.bar.example.com" ? And multiple wildcards as well? Just for
tunnel_route use case? If it's going to be an incompatible change anyway, I
think we should provide a
Let's refer to the latest specs.
https://www.rfc-editor.org/rfc/rfc9112.html#name-status-line
The reason-phrase is optional, but the SP between status-code and
reason-phrase is not. The spec clearly states it.
status-line = HTTP-version SP status-code SP [ reason-phrase ]
> A server MUST send th
like introducing TSVarLenData has more downside than the upside.
On Wed, Jan 4, 2023 at 9:13 AM Walt Karas
wrote:
> They could make the returned structure a nesting structure in their
> structure. Better to make things more convenient for the typical case, not
> the unusual ca
t allow structures as return values. So this:
>
> typedef struct
> {
> char *data;
> int length;
> }
> TSVarLenData;
>
> TSVarLenData TSSomething(x, y, z);
>
> Is another alternative.
>
> On Thu, Sep 1, 2022 at 5:32 PM Masakazu Kitajo wrote:
>
> > U
+1
- Masakazu
On Wed, Dec 14, 2022 at 11:54 AM Bryan Call wrote:
> I've prepared a release for 9.1.4. The release notes are available at:
>
>
> https://github.com/apache/trafficserver/pulls?q=is:closed+is:pr+milestone:9.1.4
>
> or for a brief ChangeLog:
>
> https://github.com/apache/trafficser
+1
- Masakazu
On Wed, Dec 14, 2022 at 12:09 PM Evan Zelkowitz wrote:
> I've prepared a release for 8.1.6. The release notes are available at:
>
>
> https://github.com/apache/trafficserver/pulls?q=is:closed+is:pr+milestone:8.1.6
>
> or for a brief ChangeLog:
>
> https://github.com/apach
M Shu Kit Chan
> wrote:
>
> > Also are we planning to eventually rewrite our existing APIs (where
> > applicable) to use this?
> >
> > On Wed, Aug 31, 2022 at 8:36 AM Masakazu Kitajo
> wrote:
> > >
> > > What's the advantage of using TSHeapBuf? Wha
Can someone tell me what should be under tscpp/api and tscpp/util ?
On Wed, Aug 31, 2022 at 5:07 AM Walt Karas
wrote:
> I propose moving Cleanup.h from plugins/xdebug to include/ts/api as a part
> of https://github.com/apache/trafficserver/pull/9044 .
>
What's the advantage of using TSHeapBuf? What issue does it solve?
On Wed, Aug 31, 2022 at 7:48 AM Walt Karas
wrote:
> Described here:
>
> https://github.com/apache/trafficserver/blob/os_pkey_cnf_reload/doc/developer-guide/api/functions/TSHeapBuf.en.rst#tsheapbufdata
> ,
>
> In PR https://githu
3646d
BoringSSL: 7f857eace90b67f45c889b9aadadb5789ad9d33c
Thanks,
Masakazu
On Tue, Aug 30, 2022 at 5:54 PM jean-frederic clere
wrote:
> On 8/29/22 17:13, Masakazu Kitajo wrote:
> > On master, h3-29 and h3-27 are supported. On the 10-Dev branch, h3 (the
> > final version) and probably h3-29 as well.
> >
&g
Dev branch.
Thanks,
Masaka
On Mon, Aug 29, 2022 at 6:46 PM jean-frederic clere
wrote:
> On 8/29/22 04:26, Masakazu Kitajo wrote:
> > Hi,
> >
> > I guess it's because of version mismatch. Our master branch has not
> > supported the final versions (0x0001 and h3).
Hi,
I guess it's because of version mismatch. Our master branch has not
supported the final versions (0x0001 and h3). If your client only
supports the final versions, it's incompatible with ATS master.
Maybe you can try our 10-Dev branch. The branch has support for the final
versions. I added
Hi all,
At the ATS Summit last week, the participants reached an agreement that we
should use an external library, Quiche, to support QUIC. I'd like to share
the reasons and make a formal (but lazy) consensus here on this list.
Main reasons to use Quiche:
- We don't have enough resource to implem
I'm +1 on adding it, but not sure about the name.
There are a couple of similar APIs such as TSVConnSslCipherGet and
TSVConnSslProtocolGet, and those start with "TSVConnSsl". TSVConnSslSNIGet
may be more consistent with existing API names. It seems like TSSsl
(without VConn) is used for APIs that
. This will take time. I think a two months
> cycle for 9.2.x as suggested in the email can work, but is likely
> optimistic.
>
> — Leif
>
> > On Sep 28, 2021, at 22:21, Masakazu Kitajo wrote:
> >
> > I understand all changes has to be landed on master firs
ike we did for 9.1.0 release, request
reviews from someone else ;-)
Masakazu
On Wed, Sep 29, 2021 at 7:31 AM Leif Hedstrom wrote:
>
>
> > On Sep 28, 2021, at 3:37 AM, Masakazu Kitajo wrote:
> >
> > Can you clarify what branching 9.2.x means (again)?
>
> It means, bra
Can you clarify what branching 9.2.x means (again)?
I don't have a strong opinion on the release date, but I think RM should
clearly call a feature freeze sooner rather than later and we all should
focus on stabilizing the branch because we already have many changes for
9.2.0.
I'm personally goin
Let's remove the APIs.
One week of silence probably means nobody cares about the APIs. If we keep
the APIs, I want the maintainer to propose the APIs as official TS APIs and
add documentation to make it clear that those are available for plugins. If
nobody volunteers, we should remove the APIs. We
Actually, I don't understand TSHttpProtocolType. Shouldn't it be
StructureType? Let's say we support a new priority scheme that is available
on both H2 and H3. What would be the TSHttpProtocolType for it?
Masakazu
On Wed, Sep 2, 2020 at 9:37 AM Masakazu Kitajo wrote:
> +1 I
+1 I'm ok with the new function signatures that use abstract structures.
However, I'm not sure if we really need that flexibility for Stream ID, I
can't say 64-bit is big enough, but I think extensibility is not
everything. Usability matters. Should we prepare for 128-bit stream ids
now? Would we
ow explicitly indicate (either via an input param or an output param)
> the actual protocol active for the given request. It seems a bit too
> confusing (and potentially problematic depending on how things evolve in
> the future) to hide that aspect.
> Thoughts?
>
>
> On Su
And there is a proposal for a new priority scheme that may be used for both
H2 and H3.
https://tools.ietf.org/html/draft-ietf-httpbis-priority-01
I haven't read it, but it would be nice if the TS API could be compatible
with the new scheme.
On Mon, Aug 31, 2020 at 10:48 AM Masakazu Kitajo
I think we should avoid adding APIs just for HTTP/2 unless it's really
HTTP/2 specific. Are we going to add TSHttpTxnClientHttp3StreamIdGet and
TSHttpTxnClientHttp3PriorityGet as well?
I'd omit the "2" in the API names, and rephrase the API doc like:
This API returns an error if the provided trans
I'd like to propose deprecating "cqhv" log field on 9.0.0.
The documentation says "cqhv" logs "Client request HTTP version", however,
it's been false for a long time because the value never be HTTP/2. What
it actually logs is "HTTP version that ATS internally uses". As some of
you may know, ATS p
Hi,
Since we have an additional branch (quic-latest) for HTTP/3 and QUIC, there
was a confusion about what branch you should make a PR for. So I'd like to
propose a guideline for HTTP/3 or QUIC related PRs below.
- Make a PR for quic-latest if the change adds new features
- Make a PR for quic-lat
Are we ok with anonymous commits like below now? I remember some of us
didn't like it before.
https://lists.apache.org/thread.html/930e933eaf6067f4ab70ec8ac3fd439d5d286d13461c1f8a402dfa87%40%3Cdev.trafficserver.apache.org%3E
commit d7345f675012c04e4d7ec36b4eaf6fc825bdf7f8
Author: Leif Hedstrom
Which building is SNVC-2? Is it Building C on Google Maps?
Thanks,
Masakazu
On Tue, Oct 1, 2019 at 1:29 AM Bryan Call wrote:
> The schedule has been created and can be found on the summit page:
>
> https://cwiki.apache.org/confluence/display/TS/Fall+2019+Summit <
> https://cwiki.apache.
ble on the page above.
Please let me know if you have any questions.
Thanks,
Masakazu
On Thu, Jul 25, 2019 at 11:58 AM Masakazu Kitajo wrote:
> Hi,
>
> As some of you may know, I created a PR (#5594) for adding experimental
> QUIC support, and its target version is 9.0.
>
>
I agree with Sudheer. There should be no difference between UnixNetVC and
SSLNetVC when calling the API with "H3" as the protocol name (H3 is only
available on QUICNetVC).
Masakazu
On Tue, Aug 6, 2019 at 8:52 AM Sudheer Vinukonda
wrote:
> Sounds reasonable to me, except I wonder if it’d make mo
Hi,
As some of you may know, I created a PR (#5594) for adding experimental
QUIC support, and its target version is 9.0.
Like we talked on the previous summit at Beijing, we are going to merge the
PR soon with Commit-Then-Review process, because QUIC spec is still
changing and making the code per
lay means ? How to reproduce it ?
>
> SCW00
>
> > 在 2018年11月19日，上午9:12，Masakazu Kitajo 写道：
> >
> > seem
>
>
Hi all,
Here is a result of ATS QUIC Hackathon at Tokyo.
We couldn't make many code changes, but we were able to find out a cause of
performance issue. This is a big win, which we couldn't make without this
hackathon.
## Input
Possible reasons of low performance:
- Send / receive packets one by
> Also don’t forget that QUIC will have to get into the mix here, and long
term, both H2 and QUIC on the outbound connections.
Yah, and QUIC would have some versions (some features are already pushed
out from the first version). This brings up one more question; Should we
also think about TLS vers
Hi,
This is a summary of a discussion about our QUIC project on the last ATS
summit.
Since every decision have to be made on ML with our community, I'm sending
this summary to make it official. Please reply to this thread if you have
any comments or questions.
# Target version
ATS 9.0 is the cur
> the person proposing a Backport should be willing and expected to make
the PR if asked
I proposed a backport but didn't make a PR for 7.1.x because I wasn't asked
to make it. Should I make the PR even if I wasn't asked to do so, or should
I wait for the request from RM?
Masakazu
On Sat, Sep 1
+1
On Tue, Jun 19, 2018 at 0:20 Derek Dagit wrote:
> +1
>
> On Mon, Jun 18, 2018 at 10:09 AM, Alan Carroll <
> solidwallofc...@oath.com.invalid> wrote:
>
> > +1
> >
> > On Mon, Jun 18, 2018 at 10:06 AM, David Calavera <
> david.calav...@gmail.com
> > >
> > wrote:
> >
> > > I noticed that atscppa
+1
On Fri, May 11, 2018 at 6:29 PM, Alan Carroll <
solidwallofc...@oath.com.invalid> wrote:
> +1
>
> On Thu, May 10, 2018 at 9:25 AM, Bryan Call wrote:
>
> > +1
> >
> > -Bryan
> >
> > > On May 10, 2018, at 2:05 PM, Susan Hinrichs >
> > wrote:
> > >
> > > I just discovered the TS API
> > >
> > >
+1
On Sat, May 12, 2018 at 9:05 PM, Leif Hedstrom wrote:
> +1
>
> — Leif
>
> > On May 12, 2018, at 11:40, Otto van der Schaaf
> wrote:
> >
> > +1
> >
> >> On Sat, 12 May 2018 at 12:35, Bryan Call wrote:
> >>
> >> +1
> >>
> >> -Bryan
> >>
> >>> On May 10, 2018, at 4:02 PM, Chris Lemmons wrote:
I prefer #2. If we started backporting new features to 7.1.x branche, the
branch would be something like another master that doesn't break
compatibility, which means it'll be unstable all the time.
I'd like to hear opinions from people who supports #1. What we need to
discuss might not be "which v
Hi there,
We have been catching up QUIC draft-07 and it's almost done, there are lots
of unimplemented features and bugs though. Since draft-08 has been
published, now quic-latest is open for changes for draft-08.
I'm not going to create draft-07 branch because other implementations are
already m
59 PM, Masakazu Kitajo wrote:
> For those who are interested in relation between QUICStream and
> HQClientTransaction,
>
> I draw a rough picture to help your understanding.
>
> From protocol perspective, HTTP is on top of TCP or QUIC. From ATS design
> perspective, Transactions
1 - 100 of 127 matches
Mail list logo
