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
*/