Skip to content

Support direct loopback HTTP export to Langfuse Docker #9

Description

@ChoMinGi

allowInsecureHttpForDevelopment(true) currently accepts a loopback HTTP endpoint, but export to a stock Langfuse Docker instance can fail before a response is received.

Reproduced with:

  • langfuse-otel-java 38aeb4e
  • OpenTelemetry 1.62.0 JDK HTTP sender
  • Langfuse v4.0.0-rc.2
  • JDK 17 on macOS/Docker Desktop

curl reaches the endpoint, and a JDK HttpClient forced to HTTP/1.1 also works. The default JDK client attempts a cleartext HTTP/2 upgrade; the Langfuse server closes that connection and the exporter reports an EOF (HTTP/1.1 header parser received no bytes). Export through a local TLS reverse proxy succeeds, including API v2 read-back.

This affects the explicit local-development HTTP path, not the default HTTPS production path.

For 0.2.1, investigate a supported transport-level fix without reintroducing the OkHttp/Kotlin classpath conflict that the JDK sender avoided. A fix should include a real Langfuse Docker regression test across the supported JDKs and preserve the existing HTTPS, redirect, authentication-header, and endpoint-security behavior.

Until then, local Docker validation should use TLS in front of Langfuse or an HTTPS-capable collector/proxy.

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions