
Looking at the headers, the big difference seems that galaxy webserver doesn't allow for "partial content"... On Jun 14, 2010, at 12:04 PM, Davide Cittaro wrote:
[stream 2 (working)]
HTTP/1.1 200 OK Date: Fri, 11 Jun 2010 13:50:29 GMT Server: Apache/2.2.8 (Ubuntu) Last-Modified: Thu, 10 Jun 2010 15:12:15 GMT ETag: "9f-42e5586-488ae729691c0" Accept-Ranges: bytes Content-Length: 70145414 Connection: close Content-Type: chemical/x-mopac-input
[stream 2 (not working)]
HTTP/1.1 200 OK Date: Fri, 11 Jun 2010 13:46:29 GMT Server: PasteWSGIServer/0.5 Python/2.6.5 content-length: 70145414 content-type: chemical/x-mopac-input Set-Cookie: galaxysession=eb142648ac45b770ddabc752e2cd511e21664b5a654cabfbe79569d4ede184379f55c5dbc9000304; expires=Thu, 09-Sep-2010 15:46:29 GMT; Max-Age=7776000; Path=/; Version=1 Connection: close
Actually no "Accept-Ranges: bytes" nor the entity tag are present, I guess the hgTracks binary can't send a request for a specific section of the file and receives the whole stream in a single request. Looking at the w3c pages: 10.2.7 206 Partial Content The server has fulfilled the partial GET request for the resource. The request MUST have included a Range header field (section 14.35) indicating the desired range, and MAY have included an If-Range header field (section 14.27) to make the request conditional. The response MUST include the following header fields: - Either a Content-Range header field (section 14.16) indicating the range included with this response, or a multipart/byteranges Content-Type including Content-Range fields for each part. If a Content-Length header field is present in the response, its value MUST match the actual number of OCTETs transmitted in the message-body. - Date - ETag and/or Content-Location, if the header would have been sent in a 200 response to the same request - Expires, Cache-Control, and/or Vary, if the field-value might differ from that sent in any previous response for the same variant If the 206 response is the result of an If-Range request that used a strong cache validator (see section 13.3.3), the response SHOULD NOT include other entity-headers. If the response is the result of an If-Range request that used a weak validator, the response MUST NOT include other entity-headers; this prevents inconsistencies between cached entity-bodies and updated headers. Otherwise, the response MUST include all of the entity-headers that would have been returned with a 200 (OK) response to the same request. A cache MUST NOT combine a 206 response with other previously cached content if the ETag or Last-Modified headers do not match exactly, see 13.5.4. A cache that does not support the Range and Content-Range headers MUST NOT cache 206 (Partial) responses. The header fields listed above are not included when galaxy tries to serve the bigWig file. Is there a way to modify this behavior (possibly with the new datatype definition...). Thanks d /* Davide Cittaro Cogentech - Consortium for Genomic Technologies via adamello, 16 20139 Milano Italy tel.: +39(02)574303007 e-mail: davide.cittaro@ifom-ieo-campus.it */