upload a file on a http/1.1 server - TCP-IP

This is a discussion on upload a file on a http/1.1 server - TCP-IP ; Hello Group members, I am implementing a http stack and need to test my APIs to upload a file on to the server and download a file from the server. The download part is easy. For upload I am using ...

+ Reply to Thread
Results 1 to 14 of 14

Thread: upload a file on a http/1.1 server

  1. upload a file on a http/1.1 server

    Hello Group members,

    I am implementing a http stack and need to test my APIs to upload a
    file on to the server and
    download a file from the server. The download part is easy.

    For upload I am using

    PUT and all required Request Headers including Expect: 100-continue.

    I do have an account on the target server, however ther server comes
    back with

    403 Forbidden

    code.

    And thus I could not proceed with sending the message body.

    I have two questions for the group and seeking any help.

    1. What is the correct way to send the request so that the server can
    replace/create new file
    at the server. In other words, how do I specify in my request that I
    want you to
    create/replace . Since sending the buffer or stream to the
    server is very easy.

    2. Secondly what can I do to do away with 403 Forbidden code from the
    server. I tried
    sending the www-authorization header initially to the server but that
    did not help either.

    Any help will be greatly appreciated.

    Thanks in advance.

    nagrik


  2. Re: upload a file on a http/1.1 server

    In article <1156359135.287270.325380@p79g2000cwp.googlegroups. com>,
    "Vinay Nagrik" wrote:

    > Hello Group members,
    >
    > I am implementing a http stack and need to test my APIs to upload a
    > file on to the server and
    > download a file from the server. The download part is easy.
    >
    > For upload I am using
    >
    > PUT and all required Request Headers including Expect: 100-continue.
    >
    > I do have an account on the target server, however ther server comes
    > back with
    >
    > 403 Forbidden
    >
    > code.
    >
    > And thus I could not proceed with sending the message body.
    >
    > I have two questions for the group and seeking any help.
    >
    > 1. What is the correct way to send the request so that the server can
    > replace/create new file
    > at the server. In other words, how do I specify in my request that I
    > want you to
    > create/replace . Since sending the buffer or stream to the
    > server is very easy.


    Many servers don't allow PUT. Often you upload files using FTP rather
    than HTTP, or they use a form to upload files.

    >
    > 2. Secondly what can I do to do away with 403 Forbidden code from the
    > server. I tried
    > sending the www-authorization header initially to the server but that
    > did not help either.


    Find a server that allows PUT.

    --
    Barry Margolin, barmar@alum.mit.edu
    Arlington, MA
    *** PLEASE post questions in newsgroups, not directly to me ***
    *** PLEASE don't copy me on replies, I'll read them in the group ***

  3. Re: upload a file on a http/1.1 server


    Barry Margolin wrote:
    > In article <1156359135.287270.325380@p79g2000cwp.googlegroups. com>,
    > "Vinay Nagrik" wrote:
    >
    > > Hello Group members,
    > >
    > > I am implementing a http stack and need to test my APIs to upload a
    > > file on to the server and
    > > download a file from the server. The download part is easy.
    > >
    > > For upload I am using
    > >
    > > PUT and all required Request Headers including Expect: 100-continue.
    > >
    > > I do have an account on the target server, however ther server comes
    > > back with
    > >
    > > 403 Forbidden
    > >
    > > code.
    > >
    > > And thus I could not proceed with sending the message body.
    > >
    > > I have two questions for the group and seeking any help.
    > >
    > > 1. What is the correct way to send the request so that the server can
    > > replace/create new file
    > > at the server. In other words, how do I specify in my request that I
    > > want you to
    > > create/replace . Since sending the buffer or stream to the
    > > server is very easy.

    >
    > Many servers don't allow PUT. Often you upload files using FTP rather
    > than HTTP, or they use a form to upload files.
    >
    > >
    > > 2. Secondly what can I do to do away with 403 Forbidden code from the
    > > server. I tried
    > > sending the www-authorization header initially to the server but that
    > > did not help either.

    >
    > Find a server that allows PUT.
    >
    > --
    > Barry Margolin, barmar@alum.mit.edu
    > Arlington, MA
    > *** PLEASE post questions in newsgroups, not directly to me ***
    > *** PLEASE don't copy me on replies, I'll read them in the group ***


    Barry,

    Thanks for your reply.

    I can install my own server. I have access to Apache server. How can
    I configure it to
    accept PUT request.

    Thanks.

    nagrik


  4. Re: upload a file on a http/1.1 server


    Vinay Nagrik wrote:

    > Barry,
    >
    > Thanks for your reply.
    >
    > I can install my own server. I have access to Apache server. How can
    > I configure it to
    > accept PUT request.


    Googling for 'apache put' had a detailed explanation as the first hit.
    You need to tell Apache to run a script when it gets a PUT request and
    install a script that does whatever it is you want Apache to do. Note
    that there are serious security considerations.

    DS


  5. Re: upload a file on a http/1.1 server


    David Schwartz wrote:
    > Vinay Nagrik wrote:
    >
    > > Barry,
    > >
    > > Thanks for your reply.
    > >
    > > I can install my own server. I have access to Apache server. How can
    > > I configure it to
    > > accept PUT request.

    >
    > Googling for 'apache put' had a detailed explanation as the first hit.
    > You need to tell Apache to run a script when it gets a PUT request and
    > install a script that does whatever it is you want Apache to do. Note
    > that there are serious security considerations.
    >
    > DS



    Hello Everybody,

    1. Can I upload a file on to any web server by using POST (of course
    running a script at the other end) instead of PUT.

    2. On my locally installed Apache server, I have the following lines so
    that the server should send files residing in a particular directory in
    gzipped format. However, when I tried receiving files from the
    configured directory, they are still coming in plain form

    Here is configuring information.


    SetOutputFilter GZIP


    Please note GZIP is all capital. Did I miss something or did something
    wrong in configuring my server. Please enlighten.

    Thanks.

    nagrik


  6. Re: upload a file on a http/1.1 server


    Vinay Nagrik wrote:

    > 1. Can I upload a file on to any web server by using POST (of course
    > running a script at the other end) instead of PUT.


    Yes, you just need to install an appropriate script on the other end.

    > 2. On my locally installed Apache server, I have the following lines so
    > that the server should send files residing in a particular directory in
    > gzipped format. However, when I tried receiving files from the
    > configured directory, they are still coming in plain form
    >
    > Here is configuring information.
    >
    >
    > SetOutputFilter GZIP
    >

    >
    > Please note GZIP is all capital. Did I miss something or did something
    > wrong in configuring my server. Please enlighten.


    Attaching the gzip output filter does not gzip all output. If it did,
    your server wouldn't work with any client that didn't support gzipped
    output. The gzip output filter looks at the request to see if the
    client indicated that it would be willing to accept gzipped pages, and
    if so, it then compresses the output.

    DS


  7. Re: upload a file on a http/1.1 server

    In article <1156464693.559424.7370@b28g2000cwb.googlegroups.co m>,
    "Vinay Nagrik" wrote:

    > 1. Can I upload a file on to any web server by using POST (of course
    > running a script at the other end) instead of PUT.


    When you use POST, it uploads data to the server, and the server
    provides that as input to the script associated with the URL. If the
    script puts the data into a file, then you can use this mechanism to
    upload a file.

    --
    Barry Margolin, barmar@alum.mit.edu
    Arlington, MA
    *** PLEASE post questions in newsgroups, not directly to me ***
    *** PLEASE don't copy me on replies, I'll read them in the group ***

  8. Re: upload a file on a http/1.1 server


    Barry Margolin wrote:
    > In article <1156464693.559424.7370@b28g2000cwb.googlegroups.co m>,
    > "Vinay Nagrik" wrote:
    >
    > > 1. Can I upload a file on to any web server by using POST (of course
    > > running a script at the other end) instead of PUT.

    >
    > When you use POST, it uploads data to the server, and the server
    > provides that as input to the script associated with the URL. If the
    > script puts the data into a file, then you can use this mechanism to
    > upload a file.


    Hello Barry and David,

    After reading two replies that "POST can be used for file upload"
    forces me to think that
    this feature goes directly against RFC 2616, which specifically says
    that

    "The POST ... request as a new subordinate of the resource
    identified by the Request-URI in the Request-Line."

    The RFC goes on to say for file upload a PUT method
    should be used.

    I am also confused about the difference between

    Content-Encoding and Transfer_Encoding headers.

    I understood that Content_Encoding is about the original entity and
    according to my
    understanding specifying

    Accept-Encoding: gzip should not affect the original entity. In other
    words if I specify
    Accept-Encoding in my request the proxy should not do anything with the
    original entity
    only if I specify

    TE: gzip

    then only the proxy should gzip the original entity. That is TE
    request header should
    prompt the server to reply

    Transfer-Encoding: gzip,chunked

    However, no matter what ever request header I modify the server only
    gives me the original entity gzipped by looking at the Accept-Encoding
    header and not at the TE
    request header.

    The proxy sends me

    Content-Encoding: gzip
    Transfer-Encoding: chunked

    I expected proxy to send me

    Transfer-Encoding: gzip,chunked If I specified

    TE: gzip

    Could you please explain me this phenomena about what am I missing in
    these two
    request header.

    Thanks in advance.

    nagrik


  9. Re: upload a file on a http/1.1 server


    Vinay Nagrik wrote:

    > After reading two replies that "POST can be used for file upload"
    > forces me to think that
    > this feature goes directly against RFC 2616, which specifically says
    > that


    No.

    > "The POST ... request as a new subordinate of the resource
    > identified by the Request-URI in the Request-Line."


    That is what the request *is*. I says nothing about what the request
    *does*, which could be anything from creating a file to launching a
    rocket ship.

    > The RFC goes on to say for file upload a PUT method
    > should be used.


    The RFC says that the PUT method uploads a file, that doesn't mean you
    can't upload a file some other way.

    DS


  10. Re: upload a file on a http/1.1 server


    David Schwartz wrote:
    > Vinay Nagrik wrote:
    >
    > > After reading two replies that "POST can be used for file upload"
    > > forces me to think that
    > > this feature goes directly against RFC 2616, which specifically says
    > > that

    >
    > No.
    >
    > > "The POST ... request as a new subordinate of the resource
    > > identified by the Request-URI in the Request-Line."

    >
    > That is what the request *is*. I says nothing about what the request
    > *does*, which could be anything from creating a file to launching a
    > rocket ship.
    >
    > > The RFC goes on to say for file upload a PUT method
    > > should be used.

    >
    > The RFC says that the PUT method uploads a file, that doesn't mean you
    > can't upload a file some other way.
    >


    David,

    Any thoughts about why the server encodes the entity and modifies the
    Content-Encoding header and not the Transfer-Encoding header. And what
    is the
    difference between the two, when one gets modified and when second gets
    modified.

    Thanks

    nagrik


  11. Re: upload a file on a http/1.1 server

    In article <1156872571.775289.315710@75g2000cwc.googlegroups.c om>,
    "Vinay Nagrik" wrote:

    > Any thoughts about why the server encodes the entity and modifies the
    > Content-Encoding header and not the Transfer-Encoding header. And what
    > is the
    > difference between the two, when one gets modified and when second gets
    > modified.


    Have you read the RFC 2616 explanations of these?

    Content-Encoding is typically the format of the file, while
    Transfer-Encoding is an encoding that the server performs in transit.

    --
    Barry Margolin, barmar@alum.mit.edu
    Arlington, MA
    *** PLEASE post questions in newsgroups, not directly to me ***
    *** PLEASE don't copy me on replies, I'll read them in the group ***

  12. Re: upload a file on a http/1.1 server


    Barry Margolin wrote:
    > In article <1156872571.775289.315710@75g2000cwc.googlegroups.c om>,
    > "Vinay Nagrik" wrote:
    >
    > > Any thoughts about why the server encodes the entity and modifies the
    > > Content-Encoding header and not the Transfer-Encoding header. And what
    > > is the
    > > difference between the two, when one gets modified and when second gets
    > > modified.

    >
    > Have you read the RFC 2616 explanations of these?
    >


    Barry,

    I have read RFC from ciover to cover and that is why I am confused.
    The entity at the
    client is unzipped.

    and no matter what I specify; i.e either
    Accept-Encoding: gzip,deflate
    or

    TE: gzip,deflate

    the server always respondes with

    Content-Encoding: gzip
    Transfer-Encoding: chunk

    I expect it to respond with

    Transfer-Encoding:gzip,chunked

    It does not happen. I am using Apache server.

    My question is why does the server gzips the file and modifies the
    Content-Encoding
    header not the Transfer-Encoding header.

    Thanks.

    arun


    > Content-Encoding is typically the format of the file, while
    > Transfer-Encoding is an encoding that the server performs in transit.
    >
    > --
    > Barry Margolin, barmar@alum.mit.edu
    > Arlington, MA
    > *** PLEASE post questions in newsgroups, not directly to me ***
    > *** PLEASE don't copy me on replies, I'll read them in the group ***



  13. Re: upload a file on a http/1.1 server

    On Wed, 30 Aug 2006 00:49:00 -0400, Barry Margolin wrote:

    > In article <1156872571.775289.315710@75g2000cwc.googlegroups.c om>,
    > "Vinay Nagrik" wrote:
    >
    >> Any thoughts about why the server encodes the entity and modifies the
    >> Content-Encoding header and not the Transfer-Encoding header. And what
    >> is the
    >> difference between the two, when one gets modified and when second gets
    >> modified.

    >
    > Have you read the RFC 2616 explanations of these?
    >
    > Content-Encoding is typically the format of the file, while
    > Transfer-Encoding is an encoding that the server performs in transit.


    That's not an accurate description, in fact it's very common to have
    html pages returned with Content-Encoding: gzip (that should be, and are,
    displayed as html).

    Content-Encoding is usually "stored" on the server, while
    Transfer-Encoding is applied dynamically. However that doesn't have to be
    the case.
    The best description might be with reference to other headers, like
    Range and Content-MD5. Content-Encoding comes before processing of these
    headers but Transfer-Encoding comes afterwards.

    This also somewhat answers the OP's questions, Transfer-Encoding can be
    added/removed by the server whenever it wishes. Content-Encoding, not as
    easily.

    --
    James Antill -- james@and.org
    http://www.and.org/and-httpd


  14. Re: upload a file on a http/1.1 server


    In article , James Antill writes:
    >
    > Content-Encoding is usually "stored" on the server, while
    > Transfer-Encoding is applied dynamically. However that doesn't have to be
    > the case.
    > The best description might be with reference to other headers, like
    > Range and Content-MD5. Content-Encoding comes before processing of these
    > headers but Transfer-Encoding comes afterwards.


    Per RFC 2616 3.6, the essential difference between the two is that
    "the transfer-coding is a property of the message, not of the
    original entity". That's it. Everything else follows from that:
    for example, chunking is a transfer-coding, not a content-coding,
    because it's a characteristic of the message. When the message has
    been completely received and reconstructed by the recipient, the
    transfer-coding is gone. This is the distinction drawn between
    message-body (with transfer-coding) and entity-body (without
    transfer-coding) in 4.3.

    The content-coding, on the other hand, remains after the message is
    reconstructed and the transfer-coding is removed (7.2). Removing it
    is another step; it's part of processing the entity-body contained in
    the message.

    Similarly, per 7.2.1, content-codings "are a property of the requested
    resource". Say there are two GETs for the same resource, the second
    a conditional one. If the server would serve the resource with a
    different content-coding for the second request, it must consider
    that a change and not send a 304 response. (Thus per 13.3.4, for
    example, if the first response was accompanied by a strong entity
    tag, then the second response MUST use a different entity tag if the
    content-coding is different.) Content-coding is a property of the
    entity.

    But two responses with the same content-bodies but different transfer-
    codings can be considered identical for caching purposes.

    The transfer-encoding field is hop-by-hop (13.5.1); it MUST be
    removed by proxies and gateways (19.4.6), and MAY be added or removed
    by any entity along the request-response chain (4.3).

    The distinction really isn't that complicated, and as I said every
    difference follows from the essential message/entity division. If
    you're operating at the messaging layer, you have transfer-codings;
    if you're operating higher than that, you don't.

    --
    Michael Wojcik michael.wojcik@microfocus.com

    The guy who's fast in the mountain pass is the coolest.
    -- _Initial D: Second Stage_

+ Reply to Thread