Hi community

This message is to clarify and make transparent the current situation of Public APIs, in addition to demonstrating the frustration of us maintainers. So read this if you find it interesting, please.

Well, I keep the Public APIs project together with other 3 developers (@pawelborkar, @marekdano and @yannbertrand) for a long time.

1 year ago, the Public APIs project was dead, w

expected result:
example.com?param=abc -> will become example.com
example.com/?param=abc -> will stay example.com/

actual result:
example.com?param=abc -> become example.com
example.com/?param=abc -> stays example.com/?param=abc

Issue

The response header does not reflect the correct version for HTTP2 requests. Even though, wiremock replies in h2 but the version in the response header shows "HTTP/1.1 200". This is caused by the hardcoded value in the toString() method of Response.java class

    @Override
    public String toString() {
        StringBuilder sb = new StringBuilder();
        **sb.append("HTTP

App: mautic
https://developer.mautic.org/

Triggers

• New Contact: Triggers when a new contact is created
• Updated Contact: Triggers when an existing contact is updated
• New Form Entry: Triggers when a form is submitted

Description

Once the ability to customize the sidecar and init containers is merged, there will be some existing 'band aid' configuration settings that can be deprecated, this is to track the high-level list (and maybe decide if / how / when to do those deprecations).

Annotations:

• kuma.io/sidecar-env-vars
• kuma.io/service-account-token-volume

Right now the tutorial is coherently designed, tested, and even documented. However, it doesn't build up in a way that's very beginner friendly. It establishes glom's value and then immediately uses it at an intermediate level.

I'd like it if it was a bit more drawn out to use basic features first and then add a multi-line Coalesce as the

As part of the process of making the Pact docs more user friendly, we'd like to start writing feature documentation once, and providing code examples for each of the languages, rather than everyone having to write the same docs over and over again in each language.

The documentation for the consumer version selectors can be our first opportunity to give this approach a try. I have written the beh

Describe your problem(s)

In the "Complexity Analysis" tab in GraphQL try-out page in devportal, we can see only the complexity Values of each field. If we want to know the complexity value or the depth value, we have to calculate ourself manually. Instead, it would be a nice to have feature to have the possibility to display the calculated complexity/depth values on a button click. So before

The fastapi example (and perhaps the others) are a little misleading to newbies.

The following lines would suggest that there is pact mock on the provider side, when in reality this is the address of the locally running FastAPI provider:

PACT_MOCK_HOST = 'loca