Re: Allow list for proxy.config.net.per_client.max_connections_in

> IP > > address is going to be used, that may be a reason to have the limit on > ATS > > (I assume iptables cannot handle it). > > > > -- Masakazu > > > > On Thu, Apr 17, 2025 at 2:39 PM Brian Neradt > > wrote: >

Re: Allow list for proxy.config.net.per_client.max_connections_in

0.4.0/24 Ignore a range of IP address specified by CIDR > notation. > > Here is an example YAML file ignoring some address ranges: > > allow_list: > - 10.0.2.123 > - 172.16.0.0/20 > - 192.168.1.0/24 > > Please let me know if you have suggestions or concerns

Allow list for proxy.config.net.per_client.max_connections_in

192.168.1.0/24 Please let me know if you have suggestions or concerns about this configuration. Thanks, Brian Neradt -- "Come to Me, all who are weary and heavy-laden, and I will give you rest. Take My yoke upon you and learn from Me, for I am gentle and humble in heart, and you will find

Re: [API Proposal] TSVConnPPInfoGet to access information from PROXY protocol

nd My burden is light." ~ Matthew 11:28-30 On Sun, Feb 9, 2025 at 11:32 AM Leif Hedstrom wrote: > I’m +1 too. > > Adding ProxyProtocol seems pretty long, maybe we can use PROXY (all upper > case) instead of PP, which is how it’s spelled. > > — Leif > > On Sat,

Re: [API Proposal] TSVConnPPInfoGet to access information from PROXY protocol

+1 My preference would be to spell out ProxyProtocol in the API instead of PP. But I don't feel that strongly about it though. +1 either way. On Fri, Feb 7, 2025 at 7:21 PM Masakazu Kitajo wrote: > Hi, > > I'd like to propose a new TS API to access information from PROXY protocol. > > ATS suppo

Re: [VOTE] Release Apache Traffic Server 9.2.8 (RC0)

+1 We have this running on a box in production now. It seems to be stable and handling traffic well. Thank you for working on this Evan. On Thu, Jan 30, 2025 at 10:55 PM Hiroaki Nakamura wrote: > +1 - tested on Ubuntu 22.04 (gcc, x86_64) > > 2025年1月30日(木) 6:39 Evan Zelkowitz : > > > > I've pre

Re: [VOTE] Release Apache Traffic Server 10.0.3 (RC1)

+1 The docs server is running an asan-built 10.0.3-rc1 and it is stable and Yahoo has a box running this release taking production traffic. On Wed, Jan 29, 2025 at 5:18 PM Masaori Koshiba wrote: > +1 - built and tested on macOS 15.2 with LLVM-19. > > — Masaori > > On Wed, Jan 29, 2025 at 11:12 

Re: [VOTE] Release Apache Traffic Server 10.0.2 (RC0)

+1 This is running on our docs server now and has been since yesterday. It has been stable and I've noticed no functional issues. On Wed, Nov 13, 2024 at 10:16 AM Chris McFarlen wrote: > +1, built and tested on ubuntu, unit tests pass. > > Chris > > Sent with Proton Mail secure email. > > On We

Re: [VOTE] Release Apache Traffic Server 10.0.1 (RC1)

+1 I updated the docs server with this and it is running fine. Thank you Chris. On Fri, Oct 25, 2024 at 11:05 AM Bryan Call wrote: > +1 - Tested on Fedora 40 > > -Bryan > > > > On Oct 16, 2024, at 9:13 AM, Chris McFarlen wrote: > > I've prepared a release for 10.0.1. Changes since the last rel

Re: [VOTE] Release Apache Traffic Server 10.0.0 (RC0)

+1 The opensource Traffic Server docs server has run an ASAN build of the rc0 tag since yesterday and it has been stable. Yahoo has run this build on a prod server in production since yesterday and it is running stable with expected throughput and response code metrics. On Wed, Aug 21, 2024 at 9

Re: [VOTE] ACL filter action names for 10.x

w Williams wrote: > I’d vote for 2. Rename them and we can make the allow/deny actions a > syntax error so they get caught early. > > Something I wasn’t clear on, Can you confirm that this is planned for ATS > 11 or 10.x - not the upcoming release of 10? > > Matt > > On 2

Re: [VOTE] ACL filter action names for 10.x

mething I wasn’t clear on, Can you confirm that this is planned for ATS > 11 or 10.x - not the upcoming release of 10? > > Matt > > On 2024/07/22 17:44:27 Brian Neradt wrote: > > Hi dev@trafficserver.apache.org, > > > > We're processing through ACL filter action

Re: [VOTE] ACL filter action names for 10.x

e old names will be rejected with a fatal message. If I get some positive feedback on that draft, I can add some more autests for it and update the docs. On Thu, Jul 25, 2024 at 10:16 AM Chris McFarlen wrote: > +1 renaming to avoid potential user astonishment > > > > > Sent with

[VOTE] ACL filter action names for 10.x

Hi dev@trafficserver.apache.org, We're processing through ACL filter action names for 10.x. For context, for 9.x and before, these are how actions behave for ip_allow.yaml rules and remap.config ACL filters: * ip_allow.yaml: These rules currently support allow and deny actions. allow specifies an

Re: ACL filter: add add_allow and add_deny actions

Match on IP only Policy", > even if it has additional actions that you are proposing here. Sorry for > repeating myself, but the behavior still has a big trap for my users. > > > Overall, what I object is: > > A). renaming policies to "legacy" and "modern&quo

Re: ACL filter: add add_allow and add_deny actions

> > For example, when a user configures a remap rule like below, as you > described, > > ``` > map http://www.example.com/ http://internal.example.com/ \ > @action=deny @method=POST > ``` > > This allows ALL requests except POST request with "Match on IP only &

ACL filter: add add_allow and add_deny actions

Note that the production change is almost trivial: most of the change involves renaming the configuration and its associated member variables or updating some tests. Please let me know if you have any thoughts or concerns. Thank you, Brian Neradt -- "Come to Me, all who are weary and heavy-lade

Re: API Change for TSMimeHdrPrint

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 the first parameter, but I guess I'm > missing something. > > It's currently used in the API implem

Re: API Change for TSMimeHdrPrint

+1 "Come to Me, all who are weary and heavy-laden, and I will give you rest. Take My yoke upon you and learn from Me, for I am gentle and humble in heart, and you will find rest for your souls. For My yoke is easy and My burden is light." ~ Matthew 11:28-30 On Mon, Jun 10, 2024 at 3:24 PM L

Suggested ACL changes for ATS 10

Hi dev@trafficserver.apache.org, I've been working with our remap.config ACL feature some for the IP Category work I've been doing. While adding ACL autests, I've noticed some unfriendly behaviors that I'd like to address for ATS 10. For reference, here's the documentation for remap.config ACLs:

Re: New feature suggestion: ip_category for ip_allow.yaml

rly unmanageable when the data source is large, and/or > it changes frequently. > > This also implies that one IP range can have just one data source? Can it > still have multiple categories ? > > — Leif > > > On Dec 15, 2023, at 13:11, Brian Neradt wrote: > > >

Re: New feature suggestion: ip_category for ip_allow.yaml

ve the plugin handler an array of categories in the > listed order in the config yaml, And ask the handler to return either > one of the categories (that matches) or null if there is no match. > Will this be a bit more efficient or probably the same? > > Kit > > > On Mon, Nov

Re: Minimum OpenSSL version

+1 On Tue, Dec 5, 2023 at 10:07 AM Bryan Call wrote: > +1 > > -Bryan > > > > > On Nov 14, 2023, at 12:24 PM, Masakazu Kitajo wrote: > > > > 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.

Re: New feature suggestion: ip_category for ip_allow.yaml

rules. That functions in every way like the ip_allow.yaml ip_category described in the previous email. Thanks, Brian On Wed, Nov 22, 2023 at 4:29 PM Brian Neradt wrote: > dev@trafficserver.apache.org, > > Bryan Call and I have been working on an idea for ip_allow.yaml. At Yahoo, > w

New feature suggestion: ip_category for ip_allow.yaml

dev@trafficserver.apache.org, Bryan Call and I have been working on an idea for ip_allow.yaml. At Yahoo, we have an internal API which categorizes IPs under certain groups via a database lookup. Each of the IP categories have potentially different requirements for which HTTP methods are accessible

Re: [Proposal] Minimum BoringSSL version (oldest commit)

+1 On Wed, Nov 15, 2023 at 4:56 PM Masakazu Kitajo wrote: > 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,

Re: Vote: Remove autotools build files from the repository (ATS 10)

+1 Maintaining both build tools would be very burdensome. On Thu, Oct 19, 2023 at 10:36 AM Chris McFarlen wrote: > With each CI job now using cmake, the autotools configuration setup will > quickly become unusable. This is a proposal to go ahead and remove the auto > tools config from the tree

Re: [VOTE] Release Apache Traffic Server 9.2.3 (RC0)

+1. We've been running with these changes internally and they have been stable for us (Yahoo). On Mon, Oct 9, 2023 at 3: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 > >

Re: [E] Re: problem compiling

Hi jean-frederic clere, I believe these have been addressed in master already: https://github.com/apache/trafficserver/pull/9586 (Note that the description points to the libswoc change for the TextView issue you mentioned.) On Mon, Sep 11, 2023 at 10:07 AM Walt Karas wrote: > On the master bra

Re: Proposed new API: TSVConnFdGet

+1 We already have a TSVConnFdCreate, so it seems appropriate to add a getter. On Wed, Sep 6, 2023 at 5:26 PM SUSAN HINRICHS wrote: > I would like to add a convenience API to fetch the file descriptor from a > VConn object. I came across the need for this when writing a plugin > working with a

Re: [E] [VOTE] Removing example/plugins/cpp-api

+1 on deprecating cpp-api and removing the examples. On Thu, Aug 17, 2023 at 10:59 AM Leif Hedstrom wrote: > > > > On Aug 17, 2023, at 07:11, Walt Karas > wrote: > > > > Does anyone have objections to the general plan to deprecate the C++ > API? > > I’m ok deprecating it :). > > > > Since incl

Re: TS API Proposal: TS_FETCH_FLAGS_SKIP_REMAP

+1 On Mon, Aug 7, 2023 at 10:40 AM Masakazu Kitajo wrote: > > Could you achieve the same result my making > proxy.config.url_remap.remap_required overridable? > > No, I don't think I can take that approach for OCSP requests. Can we know > which requests are from FetchSM and made by ATS core for

Re: [Discussion/Proposal] Regex support in sni.yaml

> > Susan or Brian, would you describe more about these use cases? > > a). * in the middle - "foo.*.com" > b). multiple * - "*.bar.*.com" > > Why it's required or how it's useful? > > I agree with we don't need to follow the wildcard certificats > semantics (RFC6125 6.4.3) in the fqdn field if we

Re: [Discussion/Proposal] Regex support in sni.yaml

We have to keep in mind the tunnel_route use case which may use multiple match groups from various match groups within the sni: https://docs.trafficserver.apache.org/en/latest/admin-guide/files/sni.yaml.en.html#examples --- sni: - fqdn: '*.foo.com' tunnel_route: '$1.myfoo' - fqdn: '*.ba

Re: HTTP/1.1 Reason Phrases for HTTP/2 Origins

gt; I'd say we should send reason-phrase if there is a good default phrase for > a status code. > > Thanks, > Masakazu > > > On Fri, Apr 14, 2023 at 11:02 AM Brian Neradt > wrote: > > > dev@trafficserver.apache.org: > > > > The current master (10.x) bra

Re: Term standardization: dead/down server -> down server

+1 Unifying on either down or dead would probably be fine. You chose "down" which seems fine to me. In either case, not using a mix of terms will be verfy helpful. Thank you for working on this. On Thu, Apr 13, 2023 at 1:13 PM Zhengxi Li wrote: > Hi ATS dev community, > > I am writing to coll

HTTP/1.1 Reason Phrases for HTTP/2 Origins

dev@trafficserver.apache.org: The current master (10.x) branch has HTTP/2 to origin support. The HTTP/2 protocol has officially removed reason phrases from the RFC: https://www.rfc-editor.org/rfc/rfc7540.html#section-8.1.2 HTTP/2 does not define a way to carry the version or reason phrase that is

Re: Anyone have any idea where this might be coming from?

d -type f -exec grep -sH > "IP_PROTO_TAG_HTTP_3_D27" {} \; ( or an xargs equivalent) > On 2/14/2023 12:06 PM, Brian Neradt wrote: > > Hi Randy, > > Digging a bit, it looks like that symbol got removed via the following PR: > > https://github.com/apache/trafficse

Re: Anyone have any idea where this might be coming from?

Hi Randy, Digging a bit, it looks like that symbol got removed via the following PR: https://github.com/apache/trafficserver/pull/8956/files#diff-c2a97dda1459e96e086384800b0daa3e20f3f8868bd4e1db9e943e73dc26eda6L76 Off the top of my head: is it possible that cleaning your build workspace, re-confi

Suggestion for New tunnel_route Port Specification Features

dev@trafficserver.apache.org: There are situations in which an origin needs to be connected to on the same port that the client connected to ATS on. Consider the following configuration: client -> ats1 -> ats2 -> server The `client` connects to `ats1` on one of a number of possible ports over a

Re: [VOTE] new API for getting the SNI for a client connection

+1 Thanks Randall. On Tue, Oct 5, 2021 at 12:33 PM Robert O Butts wrote: > +1 > > IMO we should have APIs for all SSL/SNI data. > > On Tue, Oct 5, 2021 at 11:25 AM Leif Hedstrom wrote: > > > +1. > > > > I think the same pattern is in a couple of other “example” plugins as > > well, which could

Re: Prefetch plugin?

ugin crashes ATS for some reason. Though I had it enabled > some time ago but it was commented out of my config. I've got a couple > things to play with now I guess!! LOL > > Thanks again for the clarification and the links!!! > > > > On 9/20/2021 8:39 AM, Brian Neradt

Re: Prefetch plugin?

Hi Randy, The Prefetch Plugin is a remap plugin. Remap plugins are described here: https://docs.trafficserver.apache.org/en/latest/developer-guide/plugins/remap-plugins.en.html That means it is configured via remap.config rather than plugin.config (though some plugins are configured via both plug

Re: [VOTE] Release Apache Traffic Server 9.1.0 (RC0)

+1. Yahoo is running with (our somewhat modified version) of 9.1.0 internally. On Wed, Aug 11, 2021 at 6:35 PM Randall Meyer wrote: > +1 > > Built on macOS, tests passed. On Tuesday, August 10, 2021, 12:11:52 PM > PDT, Leif Hedstrom wrote: > > I've prepared a release for 9.1.0 (RC0), whi

Design Review Request: Log Filename Specification with stderr/stdout Support

dev@trafficserver.apache.org: There has been a request that we add the ability to redirect log output for our various logs (manager.log, diags.log, error.log, the logging.yaml logs) to stdout or stderr. This can be beneficial in AWS and other such environments that have tools to monitor a process'

Re: Design Review: How to handle negative_revalidating_lifetime

the client is better than serving that stale copy and causing other side > effects. > Tldr; I think if we adjusted the documentation to explain this somehow, > then the current behavior doesn't sound all that embarrassing to me. > PS: Just to be clear, I'm not saying we should not

Design Review: How to handle negative_revalidating_lifetime

dev@trafficserver.apache.org: Context This design review concerns proxy.config.http.negative_revalidating_lifetime and is the result of investigating the feat

Re: [E] Re: Design Review Request: Log Throttling

ing. This leaves the door open for future configuration of the various logs, not just the throttled ones. Because of this advantage, option 4 is my recommendation. Thanks! On Tue, Oct 20, 2020 at 1:59 PM Brian Neradt wrote: > Thank you Alan for the forward thinking observations. I agree th

Re: [E] Re: Design Review Request: Log Throttling

Thank you Alan for the forward thinking observations. I agree that it is wise to implement this in such a way that it at least doesn't preclude the possibility of individual log configurability that you're talking about. As we discussed offline, this change moves us in that direction by establishin

Re: Design Review Request: Log Throttling

replace each and every call to those functions. ie > Check if the throttling is enabled and call the throttled version inside > the definition of the respective methods? > > > On Oct 16, 2020, at 2:13 PM, Brian Neradt > wrote: > > > > dev@trafficserver.apache.org, >

Design Review Request: Log Throttling

nvert to these throttled versions are impacted. Let me know if you have any thoughts or ideas for improvement, either with the design or the implementation. Thanks! -- Brian Neradt 1908 S. First Street Champaign, IL 61820

Re: Proposed new TS plugin API function: TSHttpHdrSchemeGet

+1 Traffic Dump can make use of this. On Mon, Sep 28, 2020 at 7:38 PM Walt Karas wrote: > This should get the scheme for the request. This differs from > `TSUrlSchemeGet` in that it gets the scheme even if it is not in the URL of > the request. For most proxy requests, the ATS core will remove

Re: [E] TS API Review: New HTTP/2 stream id and priority getters

Brian Neradt wrote: > Correct, a regular C struct. > > On Wed, Sep 2, 2020 at 11:28 AM Leif Hedstrom wrote: > >> >> >> > On Sep 1, 2020, at 3:11 PM, Alan Carroll >> wrote: >> > >> > Sorry for chiming in late - >> > >> > N

Re: [E] TS API Review: New HTTP/2 stream id and priority getters

Correct, a regular C struct. On Wed, Sep 2, 2020 at 11:28 AM Leif Hedstrom wrote: > > > > On Sep 1, 2020, at 3:11 PM, Alan Carroll > wrote: > > > > Sorry for chiming in late - > > > > Note this is extremely similar to IP addresses and I recommend we use the > > same solution. That is, there is

Re: [E] Re: TS API Review: New HTTP/2 stream id and priority getters

version 3 values of these. Notice that the above are generic to the specific HTTP protocol type used by the transaction. I'll hold off on updating the docs in the PR until I get confirmation that this looks OK to the community. Thanks, Brian On Tue, Sep 1, 2020 at 4:20 PM Brian Neradt

Re: [E] Re: TS API Review: New HTTP/2 stream id and priority getters

This sounds good to me. This essentially puts the type parameter in the structure itself rather than as a separate parameter to the functions. On Tue, Sep 1, 2020 at 4:11 PM Alan Carroll wrote: > Sorry for chiming in late - > > Note this is extremely similar to IP addresses and I recommend we us

Re: TS API Review: New HTTP/2 stream id and priority getters

> Rather than making the API protocol specific, why not use opaque > structures, and a protocol “type” identifier returned? Even with H2 and > later H3, it’s possible things like priority keeps changing. > > The caller would of course have to type cast to the appropriate priority

Re: TS API Review: New HTTP/2 stream id and priority getters

> > stream id. > > > > > > Also, a stream id on HTTP/3 (QUIC) is 62 bit integer. > > > > > > Masakazu > > > > > > > > > On Sat, Aug 29, 2020 at 5:24 AM SUSAN HINRICHS > > wrote: > > > > > >> +1 >

TS API Review: New HTTP/2 stream id and priority getters

Hi dev@trafficserver.apache.org, It would be helpful to add HTTP/2 stream and priority support to Traffic Dump. In order for the plugin to access this information, I propose adding the following two functions to the TS API: tsapi TSReturnCode TSHttpTxnClientHttp2StreamIdGet(TSHttpTxn txnp, uint32

Proposal: extend our pre-commit hook to run autopep8

our Python code against PEP8. I created a draft PR to demonstrate what the hook's implementation would look like: https://github.com/apache/trafficserver/pull/7071 Any thoughts or concerns? Thanks, Brian Neradt -- "Come to Me, all who are weary and heavy-laden, and I will give you res

Re: New TS APIs: server side protocol stack and client cert information

we still don't > >> really support customizing the Server protocol stack the way we do > Client's > >> using proxy.config.http.server_ports (" > >> > https://docs.trafficserver.apache.org/en/latest/admin-guide/files/records.config.en.html#proxy-co

New TS APIs: server side protocol stack and client cert information

Hi dev@trafficserver.apache.org, This is for a TS API update review. To support some Traffic Dump features, I'd like to update the TS API in the following ways: 1. Add TSHttpTxnServerProtocolStackGet and TSHttpTxnServerProtocolStackContains. These are the server-side analogues to the al

Re: [PROPOSAL] GitHub change to Squash and Merge

+1 On Sun, Jun 14, 2020 at 4:00 PM Evan Zelkowitz wrote: > +1 > > On Sun, Jun 14, 2020 at 2:17 PM Alan Carroll > wrote: > > > > +1 > > > > On Sun, Jun 14, 2020 at 11:27 AM Leif Hedstrom wrote: > > > > > +1 > > > > > > > On Jun 14, 2020, at 09:32, Bryan Call wrote: > > > > > > > > I would lik

Proposal for 9.x: Proxy Verifier autest Support

Context and Terminology === Traffic Server implements automated end to end testing via autest. These tests make use of a variety of tools to exercise traffic that verifies proper Traffic Server behavior. Curl, microserver, and tcp_client.py are examples of such tools. Further,

Re: Proposal for 9.x: Support external log rotation via a handled signal

rotation tools to verify custom > signals are supported. > > On Thu, Jan 23, 2020 at 11:16:25AM -0600, Brian Neradt wrote: > > > > Context > > == > > > > Traffic Server currently implements its own mechanism for rotating its > logs > > and cleani

Proposal for 9.x: Support external log rotation via a handled signal

Context == Traffic Server currently implements its own mechanism for rotating its logs and cleaning up (i.e., deleting) rotated logs based upon configured constraints. These features seem to have been developed at a time when third party tools for managing such logs were non-existent or immatu