Re: Using Apache Traffic Server as HTTP client to store some content in the storage

o download the content in order to push it into >> the ATS. >> The content that I want to write in the ATS storage is on the Internet. >> >> Regards, >> Pavel. >> >> On Wed, Apr 17, 2024 at 6:26 PM Brian Neradt >> wrote: >> >&g

Re: Using Apache Traffic Server as HTTP client to store some content in the storage

Hi Pavel, This isn't a direct answer to your question, but are you aware of the ATS HTTP PUSH feature? That allows you to push objects into the ATS cache without the typical caching of proxied response. Can that help you in this situation?

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

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: > > > > After considering

Re: New feature suggestion: ip_category for ip_allow.yaml

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 27, 2023 at 9:50 PM Brian Neradt

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

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

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

Re: download not complete_Macos

Hi Emir, I replied to the issue a few days ago: https://github.com/apache/trafficserver/issues/10826 On Wed, Nov 22, 2023 at 5:33 AM emir emron wrote: > Dear sir or madam > > Did you check it? > > best regrads > > On Sun, Nov 19, 2023 at 10:32 AM emir emron wrote: > >> Dear sir/madam >> >>

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 >

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 >

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: [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

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

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

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:

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

d 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) branch has HTTP/2 to origin suppo

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

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

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

p -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/trafficserver/pull/895

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

p -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/trafficserver/pull/895

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: 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,

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: Stale objects not delivered in case of offline parent

np. Thanks to Serris for fixing it.  On Thu, Jun 30, 2022 at 5:43 PM Matthias Kneer wrote: > Hi Brian, > > nice catch. I just built the 9.2 and tested it. It works like a charm. > Thanks a lot. > > Best regards, > Matthias > > On Thursday, June 30, 2022 22:35 CEST,

Re: Stale objects not delivered in case of offline parent

Hi Matthias, This looks like the bug which was fixed in the 9.2 release via the following PR: https://github.com/apache/trafficserver/pull/8473 Can you try upgrading and see whether that addresses your issue? Brian On Thu, Jun 30, 2022 at 10:18 AM Matthias Kneer wrote: > Hi list, > > I'm

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

Re: Prefetch plugin?

gin 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 wrote: &g

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

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),

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),

Re: Problem with logging with ver. 8.0.2

it to. Thanks, Brian On Fri, Jun 18, 2021 at 6:02 PM Brian Neradt wrote: > Just a quick follow up: I could not reproduce this locally on the 9.0.x > systems I have convenient access to. I'll try further on 8.0.x. > > Looking through commits, I notice significant changes were made around l

Re: Problem with logging with ver. 8.0.2

, On Fri, Jun 18, 2021 at 12:21 PM Brian Neradt wrote: > Thank you Lorenzo for the details. I'll investigate this today and get > back to you. > > On Fri, Jun 18, 2021 at 1:35 AM MAURIZI Lorenzo < > l.maur...@comune.jesi.an.it> wrote: > >> Unfortunately, log rol

Re: Problem with logging with ver. 8.0.2

Thank you Lorenzo for the details. I'll investigate this today and get back to you. On Fri, Jun 18, 2021 at 1:35 AM MAURIZI Lorenzo wrote: > Unfortunately, log rolling does not work, even after the changes: the new > logs are written onto the rotated log file. > > > > Here is the directory

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

Re: Design Review: How to handle negative_revalidating_lifetime

nd 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 change the current > behavior in favor of a better alternative

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

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

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 that it is > wise to imp

Re: Design Review Request: Log Throttling

d 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

tled 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] Re: [PROPOSAL] TS API for Status,Note,Warning,Alert

+1 On Tue, Sep 8, 2020 at 4:00 PM Sudheer Vinukonda wrote: > Generally +1 on exposing the API, but, just wondering if there is a > possibility that we can write a single API that takes the log type as an > input instead of having to clone a new API for each log type? > > Thanks, > > Sudheer > >

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 - >> > >>

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 wrote

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

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

ol 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 > struct. However, I don’t feel super st

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

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

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,

Proposal: extend our pre-commit hook to run autopep8

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 rest. Take My yoke

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-config-http-

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

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

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