小编Ste*_*man的帖子

我有一个ServiceStack服务,使用RequestContext.ToOptimizedResult()例如:压缩响应

[Route("/numbers/search")]
public class FindNumbers
{
}

public object Get(FindNumbers query)
{
    var data = new List<string> { "One", "Two", "Three" };
    return RequestContext.ToOptimizedResult(data);
}

这在发出如下请求时非常有效:

GET http://myhost:13487/numbers/search.json

并使用Accept-Encoding请求标头按预期压缩:

Accept-Encoding: gzip,deflate,sdch

我也可以发出JSONP请求:

GET http://myhost:13487/numbers/search?callback=func

它正确返回一个application/javascript回调(未压缩).

问题

当我将Accept-Encoding请求标头添加到JSONP请求时,响应是根据原始JSON请求的压缩JSON数据,而不是压缩application/javascript回调.

是否有任何明显的原因导致我对此行为缺失,或者它只是ServiceStack中的一个错误？我的期望是在响应中接收压缩的JSONP回调,但我对JSONP相当绿,并且可能有一个很好的理由进行回退.

请注意,我正在通过ServiceStack源进行工作,但我认为我会在那里得到它,因为更多的大脑比一个更好...

提前致谢

编辑

所以,我已经从以下来源追踪了这个问题

https://github.com/ServiceStack/ServiceStack/blob/5d09d439cd1a13712411552e2b3ede5a71af2ee5/src/ServiceStack/Host/Handlers/GenericHandler.cs#L79

和

https://github.com/ServiceStack/ServiceStack/blob/5d09d439cd1a13712411552e2b3ede5a71af2ee5/src/ServiceStack/Host/RestHandler.cs#L107

if (doJsonp && !(response is CompressedResult))
    return httpRes.WriteToResponse(httpReq, response, (callback + "(").ToUtf8Bytes(),")".ToUtf8Bytes());

return httpRes.WriteToResponse(httpReq, response);

因此,如果响应是压缩结果,那么无论通过?callback=func响应对JSONP的要求如何,都只包含压缩的json(在上面的示例中),这与我上面的发现完全一致.所以看起来需要在callstack中更早地应用jsonp回调包装器.

我正在使用 RoundhouseE 来管理数据库迁移，并且由于旧版 git 配置错误，脚本已提交到 git，但行结尾不一致。我想标准化这些行结尾，当然，这样做时 RoundhouseE 会检测到这些文件的哈希更改。

从 RoundhouseE 的角度来看，我认为这是正确的行为，但我不确定修复的最佳途径。我们已经在生产数据库了。

我有点不知道继续进行的最佳方式，因此到目前为止还没有进行太多研究，很乐意在评论中与有经验的人进行讨论。

选项1

首先提交一个 UPDATE 脚本，将 [RoundhouseE].[ScriptsRun] 哈希表引导至已更改的新一次性脚本的正确哈希值。然后提交一次性脚本。我真的不喜欢这种方法，感觉又脏又老。