Hi,

First of all, very interesting project!

I'm implementing the Vulcain Gateway server in my application and it's performing slow. To be sure it's not the fault of my application I downloaded and ran the demo and this is also slow at preloading the relations. It looks like Vulcain is preloading every relation in the main request and slowing down the request when it's calling the 'conferences' endpoint:
This is in contrast to the slide in the Symfonycon slides, where the preloading 'conferences' request takes about the same time (bit more than 4sec) it needs to request the 'conferences' endpoint without preloading:

I'm not sure if this is how Vulcain is supposed to work, but if it is I don't really see how Vulcain can be faster than GraphQL for example?

Hello, everybody! Cool idea, cool project!

But i'm not understand how to modify my current scheme to use Vulcain.

Now:

(https, http/2)-> Traefik -(http)-> Nginx -(static or fastcgi)-> php-fpm (ApiPlatform)

• Traefik is my ingress controller with auto routing to some microservices via docker labels. +http/2 endpoint.
• Nginx handles static files and routes dynamic to php-fpm.

1. How it will looks with Vulcain?
2. Where should be Varnish?

There is a mention about using GraphQL as a query language for Vulcain here : https://github.com/dunglas/vulcain/blob/master/docs/graphql.md#using-graphql-as-query-language-for-vulcain

I've been playing on a toyproject about Vulcain and I'm wondering if all GraphQL queries can be converted to a HTTP Request using Vulcain, and especially, deep arguments like the following :

Given this query

{
  persons(orderBy: name_ASC) {
    id
    name,
    starships(type: destroyer) {
      name,
      weapons(category: nuclear) {
        name
      }
    }
  }
}

I believe it may be translated to the following requests :

GET /persons?orderBy=name
Preload: /*/starships/*/weapons

[
  {
    "id": "/persons/1",
    "name": "Person 1",
    "starships": "/starships?person=/persons/1&type=destroyer"
  } 
]

GET /starships?person=/persons/1&type=destroyer

[
  {
    "id": "/starships/1",
    "name": "Starship 1",
    "weapons": "/weapons?starship=/startships/1&category=nuclear"
  }
]

GET /weapons?starship=/startships/1&category=nuclear

[
  {
    "id": "/weapons/1",
    "name": "Weapon 1",
  }
]

Now It's easy to change weapons(category: nuclear) to weapons(category: explosives) in GraphQL, but I'm not sure how to do it with Vulcain. Do you have any insight about this problem?

• Bumped Go to v1.16, updated modules with go mod tidy

• Update ci.yml: golang-ci Actions job acting flaky when staging my PR. Linter is now pinned to the same go version the project is using at 1.16. Also configured it to only run against newly committed code when triggered by a pull_request. A merge into main from a PR will still trigger a full run of the golang-ci linter suite against the codebase.

• Allow to select specific media types as requested in #46 but also specific relation types and languages
• Allow to select all links by passing an empty string (best used with the new rel parameter
• Switch to the format defined in the structured headers I-D
• Add an "Implementation Status" section (RFC6982
• Add an "Acknowledgment" section

@andrerom could you review this change? It should address the eZ Publish's use case (closes #46). @evert as discussed during API Days Interface, this change to the spec should allow to cover the use cases also covered by your Prefer-Push I-D. Would you mind to take a look?

Thanks!

While AGPL is a valid license, it might be blocking the usage of Vulcain in enterprise environments (legal considerations). Is there any reason to not publish it under an even more less restrictive license as MIT?

Hi,

I noticed that the link to IETF page (https://datatracker.ietf.org/doc/draft-dunglas-vulcain/) from README page is not working. I tried to find correct link on IETF website but could not find it.

Is it because the request for this new standard is not registered yet by IETF?

Laurent

I am working on a (WIP) implementation of parts of the Vulcain protocol to be used in a server less (OpenWhisk) environment here: https://github.com/trieloff/helix-vulcain-filters

Is it ok to use the term "Vulcain" in the project name?

Vulcain's approach is quite intriguing. However major browsers per my understanding have deprecated the h2 server push feature.

Does this mean that vulcain in current state is unusable?

I understand that it might make use of Early Hints feature in the future.

• Make the library usable with any Go HTTP handler or reverse proxy, including Caddy server
• Improve the documentation
• Add an example
• Switch from Logrus to Uber Zap

Hi Dunglas,

I see examples and I have to say that the object attribute is a little weird for me..

This key name is coming for your conception or from another architecture?

IMHO, I'll prefer to use a key name named like content or value or more specific to Vulca(i)n outbreak or rash.

Thanks for reading !

Hello,

When I fetch a resource with a "fields" query parameter, the received fields are percent encoded. But when I vanilla fetch or header-based-fields fetch, the resource's fields are "normal".

Front scenario A What I code:

const eventResp = await fetch("https://localhost:8000/events/2?fields=\"\/subtitle\",\"name\"")
console.log(await eventResp.json())

What it outputs:

Object { subtitle: "Internationaux%20de%20France%20de%20tennis%202019", name: "Roland%20Garros%202019" }

ScenarioB What I code:

const eventResp = await fetch("https://localhost:8000/events/2")
console.log(await eventResp.json())

What it outputs:

Object { "@context": "/contexts/Event", "@id": "/events/2", "@type": "https://schema.org/Event", id: 2, name: "Roland Garros 2019", subtitle: "Internationaux de France de tennis 2019", heading: "120ème édition des Internationaux de France de tennis sont le plus grand tournoi de la saison de tennis sur terre battue.", startDate: "2019-05-26T00:00:00+00:00", endDate: "2019-06-09T00:00:00+00:00", visibility: "public", … }

Back PHP 6.1 / APIP 3.0.3, served by Caddy 2.6

localhost:8000

log

route {
    root * /app/public
    vulcain
    push
    php_fastcgi backend:9000
    encode zstd gzip
    file_server
}

Another proof/test with Postman (see screenshot here)

1. Is it intended?
2. What can I do to avoid this behavior?
3. Do you need more information from my context?

Thank you!

This makes Vulcain sends 103 Early Hints responses when server-push isn't supported (with preload links). The patch might be very naive but here we are, first contrib in Go. Please tell me if there is something else to be done.

When making API calls from http://localhost:19006 push seems to be working fine and it loads 400 requests in a few seconds however when I try via 192.168.1.181:19006 or on my iOS app making fetch requests it seems to be failing and loading them normally which takes over 30s.

I'm using the API Platform Docker for the backend. Any help would be appreciated

I was working in a Api Platform app with Caddy behind a IIS server. The IIS server manages HTTP/2 and stream the headers in lowercase to the Caddy server running HTTP/1.1. According to the RFC, the HTTP/2 headers should be case-senstive and with all headers in lowercase, and the HTTP/1.1 should be case-insensitive. The code that extracts the headers only verifies the "Field" header, in a case-sensitive manner, causing that the Fields header can not be readed correctly. I would try to test a patch, but I don't know Go, so I can't guarranty nothing.

Hi! I'm playing with Vulcain but i'm facing to an issue... I've 2 entities in an Api Platform project (greeting and author, author have many greetings, for relationship)

If i fetch greetings endpoint:

window.fetch('https://localhost/greetings', {
        headers: {
            preload: '"/hydra:member/*/author"',
            fields: '"/hydra:member/*/@id", "/hydra:member/*/name", "/hydra:member/*/author/@id"'
        }
    }).then(() => window.fetch('https://localhost/authors/1'))

Of course authors/1 exists and it linked to all my greetings for more simplicity.

So... In this case, with fields contains "/hydra:member/*/authors/@id" (it the same with firstname or anyother property) push doesn't work

But if instead "/hydra:member/*/authors/@id", i've "/hydra:member/*/authors" (without /@id) push works (but i get full object after, of course)

What am i missing....? Documentation seems clear about, i think this should work...

In the Cache-Documentaion there is a broken link to X-Key. https://github.com/dunglas/vulcain/blob/main/docs/cache.md

Broken in Master-Branch https://github.com/varnish/varnish-modules/blob/master/docs/vmod_xkey.rst

Branch 6.5 is available https://github.com/varnish/varnish-modules/blob/6.5/docs/vmod_xkey.rst