我注意到我的一些gzip解码代码似乎无法检测到损坏的数据.我认为我已将问题追溯到Java GZipInputStream类.特别是,当您使用单个"读取"调用读取整个流时,损坏的数据似乎不会触发IOException.如果您在同一个损坏的数据上读取2次或多次调用的流,则会触发异常.
在考虑提交错误报告之前,我想看看社区在这里想到了什么.
编辑:我修改了我的例子,因为最后一个没有清楚地说明我认为是什么问题.在这个新的例子中,gzip压缩了一个10字节的缓冲区,修改了gzip压缩缓冲区的一个字节,然后对其进行了解压缩.对'GZipInputStream.read'的调用返回10作为读取的字节数,这是您对10字节缓冲区的期望.然而,解压缩的缓冲区与原始缓冲区不同(由于损坏).没有异常被抛出.我注意到在读取后调用'available'会返回'1'而不是'0',如果已达到EOF,则会返回.
这是来源:
@Test public void gzip() {
try {
int length = 10;
byte[] bytes = new byte[]{12, 19, 111, 14, -76, 34, 60, -43, -91, 101};
System.out.println(Arrays.toString(bytes));
//Gzip the byte array
ByteArrayOutputStream baos = new ByteArrayOutputStream();
GZIPOutputStream gos = new GZIPOutputStream(baos);
gos.write(bytes);
gos.finish();
byte[] zipped = baos.toByteArray();
//Alter one byte of the gzipped array.
//This should be detected by gzip crc-32 checksum
zipped[15] = (byte)(0);
//Unzip the modified array
ByteArrayInputStream bais = new ByteArrayInputStream(zipped);
GZIPInputStream gis …在JUnit的每一个版本我都试过(高达4.8.1),一个失败的assertThat显示,看起来像一个错误信息:
预期:[describeTo]
得到:[对象的字符串表示]
换句话说,它将显示对象的toString()而不是匹配器中的不匹配描述.如果我使用org.hamcrest.MatcherAssert.assertThat的assertThat,那么它会调用"describeMismatch",并显示一个更实用的错误消息.
我是否正确使用Junit,或者目前没有JUnit版本能够满足我的需求吗？那么大多数人都会使用Hamcrest声明吗？
在我们的Rails应用程序中,用户通常会一次打开多个浏览器选项卡数小时或数天.在其中一个选项卡中,用户注销然后重新登录(或会话过期并创建新会话)时会出现问题.
这会导致所有其他选项卡上的CSRF真实性令牌变为无效.如果他们试图提交任何形式或就这些选项卡的任何Ajax请求无需刷新,他们将得到一个错误(而事实上得到登出,因为这是当一个坏的真实性令牌传递默认Rails的行为).
这种行为显然是不可取的.我想知道人们如何优雅地处理用户有一个窗口打开你的网站,但真实性令牌已过期的情况.
我不想做的只是将它们重定向到登录页面,因为这样他们可能会丢失他们的工作,例如他们已经写了很长的博客文章或其他东西.
想到的解决方案是使用一些javascript来轮询服务器以检查真实性令牌是否已更改,或者轮询用户的cookie以检查会话是否已更改.我从来没有听说有人做过这些,所以我想看看社区的想法.