8 Replies Latest reply: Jan 27, 2012 2:49 AM by alexeyo RSS

    Why does LrHttp.get add Content-Type=text/plain explicitly to headers ???

    alexeyo

      Hi everybody,

       

      I'm not just curious about my subject,- this is really serious as far as it breaks an idea of Live SkyDrive plugin development.

      When I make a very simple call to Windows Live REST API via LrHttp.get I always get error response from Live services API

      saying that Content-Type header is not expected with http "GET" verb! And, yes, IMHO people from MS are right: what is a reason to

      add such header if HTTP GET doesn't imply request-body ? Did somebody here also notice this strange behavior and know how to make

      LrHttp.get behave more "politely"? Because, I'm about to consider this as a bug

       

      Thanks.

        • 1. Re: Why does LrHttp.get add Content-Type=text/plain explicitly to headers ???
          johnrellis MVP

          Seems like a bug to me.  Also, it doesn't seem possible to suppress the Content-Type header -- you can only change it by passing {{field = "Content-Type", value = newvalue}}.  You should file a bug report in the feedback forum:

           

          http://feedback.photoshop.com/photoshop_family/products/photoshop_family_photoshop_lightro om

           

          I'm guessing that most services would just ignore the Content-Type header, so this hasn't arisen before; but Microsoft is certainly implementing the HTTP protocol correctly. (As a rule with exceptions, I prefer implementations that strictly follow standards -- I've learned over the decades that it saves much grief in the long run.)

          • 2. Re: Why does LrHttp.get add Content-Type=text/plain explicitly to headers ???
            johnrellis MVP

            I see that you did submit it to the feedback forum, good.

            • 3. Re: Why does LrHttp.get add Content-Type=text/plain explicitly to headers ???
              alexeyo Community Member

              I've gotten stuck with this. I thought, I had already overcome many complex issues and now everything is so straight-forward ... API is properly designed, it is standard conformant and is well-documented (damn ... the best documentation I've ever seen for RESTful API).

              And I didn't expect such a trip up in Lr API. Simply shoked

              I'm blocked and see only two possible solutions:

              1. Adobe accept this as a bug and fix it, but the fix will be available only in the final version of Lr 4. Bad, nothing else actually prevents me to make my plugin Lr3 compatible too

              2. Microsft will relax their strictness. But why should they do this? Their behavior is correct! Respect People usually blame MS for standards ignorance, its not a case now ...

               

              I agree with you! This strictness is absolutely reasonable and can save us developers in a modern wild world

              • 4. Re: Why does LrHttp.get add Content-Type=text/plain explicitly to headers ???
                areohbee Community Member

                Are you familiar with http proxy-ing?

                • 5. Re: Why does LrHttp.get add Content-Type=text/plain explicitly to headers ???
                  alexeyo Community Member

                  Hello Rob,

                   

                  I'm not sure what do you mean by http "proxy-ing". If you propose, to setup a web application which will work as proxy between Lr SDK stuff and Live API, - unfortunately its not a solution for me due to such reasons:

                  1. No reliability for end-users

                  2. I have no web-hosting capabilities and do not plan to pay for and maintain web-resource just to by-pass this bug in SDK

                  3. IMHO: regular plugin developer like me, should not put so much efforts to overcome such bugs

                  • 6. Re: Why does LrHttp.get add Content-Type=text/plain explicitly to headers ???
                    areohbee Community Member

                    The proxy works on your local host.

                     

                    It as an app that forwards http requests and replies, except you'll be able to control the http header.

                     

                    1. It's plenty reliable. Almost all corporate users connect to the internet through a proxy. In fact, most local users connect to the internet via a proxy too (their routers).

                    2. No host required - it runs on your local machine.

                    3. No argument. This workaround is proposed so you can meet your goal, not to let Adobe off the hook.

                     

                    PS - I use an FTP "proxy" app because it's more reliable than doing the FTP via plugin/SDK.

                     

                    Cheers,

                    Rob

                    • 7. Re: Why does LrHttp.get add Content-Type=text/plain explicitly to headers ???
                      johnrellis MVP

                      To build on Rob's reply, I think there are a number of open-source lightweight HTTP proxy/Web servers out there that might already provide the capability of removing the Content-Type header on GET requests or could be straightforwardly modified to do so.  These proxy servers are quite reliable, run on the same machine as LR, have a small memory footprint, are fast to start, and run on both Mac and Windows.   You might start with "lighthttpd".

                       

                      But it is annoying to have to work around bugs in the SDK.

                      • 8. Re: Why does LrHttp.get add Content-Type=text/plain explicitly to headers ???
                        alexeyo Community Member

                        Hello,

                         

                        >> To build on Rob's reply, I think there are a number of open-source lightweight HTTP proxy/Web servers out there that might already provide the capability of removing the Content-Type header on GET requests or could be straightforwardly modified to do so.

                         

                        It could be a solution. Before, I plan to use some cross-platform http client application like curl or wget  only for http GET requests to the Live API server . This should work ok.

                         

                        >> You might start with "lighthttpd".

                         

                        I'm familiar with this server I currently run it on my home router for the small site which acts both as data agregator and proxy at the same time. So it was my choice as well

                        I'm slowly calming and recovering after this trip-up in API and soon will start looking for some workarounds

                         

                        Thanks for suggestions!