我只是注意到使用.NET HttpWebRequest,我没有从服务器获取gzip的内容(运行nginx 0.8.52).使用curl进行测试,我验证了gzip是在服务器端正确设置的,然后用VS调试器挖掘问题.
罪魁祸首是如何Accept-Encoding生成标题字段:如果我设置
request.AutomaticDecompression = DecompressionMethods.GZip |
DecompressionMethods.Deflate`
我得到以下标题:
`Accept-Encoding: gzip, deflate,gzip, deflate`.
如果我订
request.AutomaticDecompression = DecompressionMethods.GZip;
我明白了
Accept-Encoding: gzip,gzip
我没有检查HTTP规范说的是什么,但是nginx应该处理这种情况,而是返回它Vary: Accept-Encoding.另一方面,Accept-Encoding生成的标题HttpWebRequest肯定看起来不对,对我来说似乎是个错误.
如果我没有指定AutomaticDecompression并手动设置Accept-Encoding标题,我会重新获得gzip内容,但HttpWebRequest似乎非常愚蠢,并且不解码压缩流(我猜它依赖于内部IsCompressed标志而不是解析响应头).
有什么建议？
应该注意的是,涉及到身份验证; 我刚刚发现,HttpWebRequest最初会在不包含提供的凭据的情况下执行请求.对于此请求,Accept-Encoding正确指定了标头.获取401服务器响应并使用凭据重新执行请求后发生重复.
我发布了一个Microsoft Connect 错误报告.
当使用WPF数据绑定时,我显然无法做到这一点,MyCollection = new CollectionType<Whatever>( WhateverQuery() );因为绑定具有对旧集合的引用.到目前为止我的解决方法MyCollection.Clear();之后是foreach 一直在做MyCollection.Add(item);- 这对于性能和美学都是非常糟糕的.
ICollectionView虽然非常整洁,但由于它的SourceCollection属性是只读的,因此无法解决问题.糟糕,因为那将是一个很好的简单解决方案.
其他人如何处理这个问题？应该提到的是,我正在做MVVM,因此不能通过单独的控件绑定进行翻找.我想我可以制作一个ObservableCollection运动ReplaceSourceCollection()方法的包装,但在走这条路之前,我想知道是否还有其他一些最佳实践.
对于WinForms,我会将控件绑定到a BindingSource,允许我简单地更新它的DataSource属性并调用ResetBindings()方法 - presto,底层集合有效地更改.我原本期望WPF数据绑定能够支持开箱即用的类似场景吗？
示例(pseudo-ish)代码:WPF控件(ListBox,DataGrid,无论您喜欢什么)绑定到Users属性.我意识到集合应该是只读的,以避免出现的问题ReloadUsersBad(),但是这个例子的坏代码显然不会编译:)
public class UserEditorViewModel
{
public ObservableCollection<UserViewModel> Users { get; set; }
public IEnumerable<UserViewModel> LoadUsersFromWhateverSource() { /* ... */ }
public void ReloadUsersBad()
{
// bad: the collection is updated, but the WPF control is bound to the old reference.
Users = new …我有一段代码用于某些验证逻辑,其概括如下:
private bool AllItemsAreSatisfactoryV1(IEnumerable<Source> collection)
{
foreach(var foo in collection)
{
Target target = SomeFancyLookup(foo);
if (!target.Satisfactory)
{
return false;
}
}
return true;
}
这很有效,很容易理解,并且具有早期优化功能.然而,它非常冗长.这个问题的主要目的是什么被认为是可读和良好的风格.我也对表演很感兴趣; 我坚信过早的{优化,悲观化}是万恶之源,并试图避免微观优化以及引入瓶颈.
我对LINQ很新,所以我想对我提出的两个替代版本以及其他任何建议进行评论.可读性.
private bool AllItemsAreSatisfactoryV2(IEnumerable<Source> collection)
{
return null ==
(from foo in collection
where !(SomeFancyLookup(foo).Satisfactory)
select foo).First();
}
private bool AllItemsAreSatisfactoryV3(IEnumerable<Source> collection)
{
return !collection.Any(foo => !SomeFancyLookup(foo).Satisfactory);
}
我不相信V2在可读性方面提供了超过V1,即使更短.我发现V3清晰简洁,但我不太喜欢这个Method().Property部分; 当然,我可以把lambda变成一个完整的代表,然后它失去了它的一线优雅.
我想评论的是:
提前致谢 :)
我一直想为Visual Studio创建一个简单的文本操作扩展,现在我终于找到了一些时间来研究如何编写扩展.我想到的可以通过VBA宏来实现,但我宁愿将其作为"真正的"扩展来实现; 作为一个学习过程,因为我老实说不能忍受VBA.
经过大量的谷歌搜索,博客阅读,深入研究MSDN和浏览StackOverflow帖子后,我想我已经收集了足够的信息,我可以实现它 - 但我想在开始之前就是否正在接近事情的一些反馈劈开:)
我想要的是:
对于#1,似乎我必须完成一个完整的VSPackage,.vsct文件等等 - 我没有可以处理的简单易用的MEF扩展点吗？(也许是出口IWpfTextViewCreationListener和摆弄手动键盘快捷键处理 - 但这是一个主要的黑客攻击).
对于#2,我不确定如何获取ITextBuffer活动文档.我可以通过 DTE.ActiveDocument,但我不知道如何从中获得ITextBuffer.或者,我可以做一些......
var txtMgr = (IVsTextManager)ServiceProvider.GetService(typeof(SVsTextManager));
IVsTextView textViewCurrent;
txtMgr.GetActiveView(true, null, out textView);
IWpfTextView wpfViewCurrent = AdaptersFactory.GetWpfTextView(textView);
ITextBuffer textCurrent = wpfViewCurrent.TextBuffer;
......但这确实看起来像是一种迂回的做事方式？
我正在开发一个小型的C#/ WPF应用程序,该应用程序使用手工HttpWebRequest调用和JSON序列化与Ruby on Rails中实现的Web服务进行交互.没有缓存,一切都按预期工作,我也有HTTP身份验证和压缩工作.
一旦我启用了缓存,通过设置request.CachePolicy = new HttpRequestCachePolicy(HttpRequestCacheLevel.CacheIfAvailable);,就会出现问题 - 在生产环境中.当连接到一个简单的WEBrick实例时,工作正常,我HTTP/1.1 304 Not Modified按预期得到并HttpWebRequest提供缓存的内容.
当我对生产服务器尝试相同的操作,运行nginx/0.8.53 + Phusion Passenger 3.0.0时,应用程序会中断.第一个请求(未缓存)正确提供,但是在第二个请求导致304响应时,我得到一个WebException声明" 请求被中止:请求被取消. "我一调用request.GetResponse().
我通过提琴手进行连接,但这并没有帮助很多; WEBrick和nginx都返回一个空实体,尽管响应标头不同.拦截请求并更改nginx的响应头以匹配WEBrick的响应头并没有改变任何东西,导致我认为它可能是一个保持活跃的问题; 但是设置request.KeepAlive = false;没有任何改变 - 它在连接到WEBrick时不会破坏东西,并且在连接到nginx时它不会修复东西.
对于它的价值,将WebException.InnerException是一个NullReferenceException具有如下StackTrace:
at System.Net.HttpWebRequest.CheckCacheUpdateOnResponse()
at System.Net.HttpWebRequest.CheckResubmitForCache(Exception& e)
at System.Net.HttpWebRequest.DoSubmitRequestProcessing(Exception& exception)
at System.Net.HttpWebRequest.ProcessResponse()
at System.Net.HttpWebRequest.SetResponse(CoreResponseData coreResponseData)
(工作)WEBrick连接的标头:
########## request
GET /users/current.json HTTP/1.1
Authorization: Basic *REDACTED*
Content-Type: application/json
Accept: application/json
Accept-Charset: utf-8 …