Open GoogleCodeExporter opened 9 years ago
Having same issue... can't get header to work manually. Also, Auth doesn't
seem to populate headers.
Original comment by rpla...@edvisors.com
on 20 Jul 2012 at 5:38
Note, running 1.3.2 and 1.3.1. Going to try an earlier version. Great tool
<potentially>
Original comment by rpla...@edvisors.com
on 20 Jul 2012 at 5:40
[deleted comment]
There is one thing that can be a little tricky around the auth headers because
I use the stock OS X Cocoa Http client library. For Basic auth, if you specify
the authorization using the auth tab, CococaRestClient will first try a request
without the authentication header. It then needs to receive an HTTP 401
response supplying WWW-Authorization header. CocoaRestClient will then respond
with another request supplying the Authentication header with the auth info
from the Auth tab. This models how a web browser works. If you want to avoid
this behavior and only submit one request, add a headed named "Authorization"
with the value "Basic " followed by username:password base64 encoded.
It seems odd that no headers are working for you. There are some websites that
will parrot back the headers of your http request, such as
http://pgl.yoyo.org/http/browser-headers.php. You'll have to sort through the
html.
Original comment by mike.mat...@gmail.com
on 22 Jul 2012 at 1:13
Sorry for the ambiguity this is 2 separate issues. Manual headers do work, but
the Auth tab didn't insert the Auth headers into the request. However, editing
the header block is difficult as tabbing in it fails and I can't click into a
cell to edit. I have to delete the record, add a record, and enter it in
perfectly the first time--I can't seem to edit them once they're in the table.
Original comment by rpla...@edvisors.com
on 23 Jul 2012 at 2:09
Double clicking on a cell should edit that cell, I'm surprised that doesn't
work for you. Tabbing only seems to go from header to value but not down to the
next row. I might be able to fix that. Like I said earlier, Auth will only work
in a two-phase mode where the application sends an unauthorized request,
expects a 401 response back with a WWW-Authenticate header, then sends the
authorized response. I know this is inconvenient in some cases, but is a
limitation of the Cocoa/OS X http client library. The challenge-response usage
of basic auth is described in http://tools.ietf.org/html/rfc2617#section-2.
Original comment by mike.mat...@gmail.com
on 23 Jul 2012 at 2:22
I should also mention that while the challenge-response is optional for Basic
Auth, that interaction is required for Digest Auth.
Original comment by mike.mat...@gmail.com
on 23 Jul 2012 at 2:24
I'm seeing this as well. Tabbing produces the following error in the console,
which renders the cells unusable (any edits are discarded):
31/10/12 9:26:52.196 PM CocoaRestClient[43829]: *** -[__NSArrayM
objectAtIndex:]: index 5 beyond bounds [0 .. 4]
31/10/12 9:26:52.198 PM CocoaRestClient[43829]: (
0 CoreFoundation 0x00007fff8c9e80a6 __exceptionPreprocess + 198
1 libobjc.A.dylib 0x00007fff8a73c3f0 objc_exception_throw + 43
2 CoreFoundation 0x00007fff8c984ebc -[__NSArrayM objectAtIndex:] + 252
3 CocoaRestClient 0x00000001000047b4 CocoaRestClient + 18356
4 AppKit 0x00007fff89623faa -[NSTableView textDidEndEditing:] + 481
5 CocoaRestClient 0x000000010000cca2 CocoaRestClient + 52386
6 CoreFoundation 0x00007fff8c99a47a _CFXNotificationPost + 2554
7 Foundation 0x00007fff8b72d846 -[NSNotificationCenter postNotificationName:object:userInfo:] + 64
8 AppKit 0x00007fff892fbb7a -[NSTextView(NSSharing) resignFirstResponder] + 736
9 AppKit 0x00007fff891c57d8 -[NSWindow makeFirstResponder:] + 430
10 AppKit 0x00007fff891c5f23 -[NSWindow endEditingFor:] + 391
11 AppKit 0x00007fff89275b9e -[NSTableView _endMyEditing] + 116
12 AppKit 0x00007fff89276015 -[NSTableView reloadData] + 201
13 AppKit 0x00007fff89219a59 -[NSApplication sendAction:to:from:] + 342
14 AppKit 0x00007fff892198b7 -[NSControl sendAction:to:] + 85
15 AppKit 0x00007fff892197eb -[NSCell _sendActionFrom:] + 138
16 AppKit 0x00007fff89217cd3 -[NSCell trackMouse:inRect:ofView:untilMouseUp:] + 1855
17 AppKit 0x00007fff89217521 -[NSButtonCell trackMouse:inRect:ofView:untilMouseUp:] + 504
18 AppKit 0x00007fff89216c9c -[NSControl mouseDown:] + 820
19 AppKit 0x00007fff8920e60e -[NSWindow sendEvent:] + 6853
20 AppKit 0x00007fff8920a744 -[NSApplication sendEvent:] + 5761
21 AppKit 0x00007fff891202fa -[NSApplication run] + 636
22 AppKit 0x00007fff890c4cb6 NSApplicationMain + 869
23 CocoaRestClient 0x0000000100001914 CocoaRestClient + 6420
)
Original comment by t...@thecocoabots.com
on 31 Oct 2012 at 10:29
Thanks for the stack trace, I'll check it out. Is there a repeatable sequence
of actions that causes this to happen every time? Such as: add 3 rows, delete
the middle row, click the last row, etc... ?
Original comment by mike.mat...@gmail.com
on 31 Oct 2012 at 12:10
Sorry Mike, it doesn't happen due to any consistent pattern. So far, it has
happened every time that I've tried to use the app. I wish I could give you a
repeatable set of actions!
Original comment by t...@tonyarnold.com
on 1 Nov 2012 at 12:44
Ok thanks, I'll take a look at it in a few days and see what I can turn up.
Original comment by mike.mat...@gmail.com
on 1 Nov 2012 at 12:50
Thanks for the stack trace, by the way, that should be very helpful.
Original comment by mike.mat...@gmail.com
on 1 Nov 2012 at 12:51
Original issue reported on code.google.com by
einar.vo...@gmail.com
on 10 Apr 2012 at 8:11