Resteasy を使用して小さな JAX-RS アプリケーションを開発しています。Javascript や CSS ファイルなどの静的コンテンツを提供するアプリケーションが必要でした。また、 webjars.orgの jar にパッケージ化されたリソースの既に gzip されたバージョンを利用したいと考えています。したがって、ヘッダーを処理し、Accept-Encoding
ヘッダーが存在するかどうかを確認する必要.gz
があります。
これまでのところ、私が持っているものは次のとおりです。
@Path("res/{path:.*}")
@GET
public Response webjars(@PathParam("path") String path, @HeaderParam("Accept-Encoding") String acceptEncoding) {
// Guesses MIME type from the path extension elsewhere.
String mime = mimes.getContentType(path);
if (acceptEncoding.contains("gzip")) {
InputStream is = getClass().getResourceAsStream("/META-INF/resources/webjars/" + path + ".gz");
if (is != null)
return Response.ok().type(mime).encoding("gzip").entity(is).build();
}
InputStream is = getClass().getResourceAsStream("/META-INF/resources/webjars/" + path);
if (is != null)
return Response.ok().type(mime).entity(is).build();
return Response.status(Status.NOT_FOUND).build();
}
しかし、うまくいきません。提供されるコンテンツは完全に壊れています。これまでのところ、ストリームを再度圧縮するコンポーネントが見つかりました: org.jboss.resteasy.plugins.interceptors.encoding.GZIPEncodingInterceptorは、メソッドを使用して手動Content-Encoding
でヘッダーを埋めたためResponseBuilder.encoding
です。
どうやら、既に gzip されたストリームを共有する方法がないため、これはバグのように見えます。ただし、これは JAX-RS を使用して達成できますか? これは Resteasy のバグですか?
webjars.org サーブレットをマッピングするなど、Resteasy の外部で同じことを実現するさまざまな方法を考えることができます (私はサーブレット API 3.0 環境にいないので、META-INF/resources/
自動クラスパス マッピングはありません)。それにもかかわらず、私の質問は依然として優勢です。これは、他のいくつかのシナリオに適用されます。
アップデート:
記録のために、問題RESTEASY-1170に記入しました。